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ABSTRACT 


This research entails the design and development of an automated system that allows 
researchers working remotely to store, manage, and transfer assertion data to an external 
system run by the Intelligence Advanced Research Projects Activity. The research stems 
from the University of Maryland's involvement in the Social-Cultural Content in 
Language program, which seeks to investigate methodologies, designs, and technologies 
that can contribute in the understanding of the social goals of persons or groups of people 
by demonstrating a relationship between these goals and their particular language use. 

In this research, we interview the stakeholders to determine the software 
requirements of the system. After a careful analysis of the requirements, we used the 
Unified Modeling Language notation to provide the reader a visual model of the software 
design. Finally, we develop a working prototype of the proposed system consisting of 
two Web services and a Web service client written in the Java programming language. 
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I. 


INTRODUCTION 


A. THE PROBLEM 

In December of 2008, the Intelligence Advanced Research Projects Activity 
(lARPA) released a Broad Agency Announcement (BAA) soliciting proposals for the 
Social-Cultural Content in Language (SCIL) Program. The intent behind the SCIL 
program is to investigate methodologies, designs, and technologies that can contribute in 
the understanding of the social goals of persons or groups of people by demonstrating a 
relationship between these goals and their particular language use (lARPA, 2008). By 
language use, we mean their “manner of speaking” as opposed to the language itself 
(e.g., Spanish, French). Anyone contributing to SCIL would be required to use Natural 
Language Processing techniques to provide information to Intelligence analysts so that 
they could advise high-level decision makers. Insight into the social dynamics of a group 
would allow analysts to better understand the strengths and weaknesses of a group, help 
identify the group’s goals and motivation, and to reduce Anglo-centric assumptions about 
their behavior (lARPA, 2008). 

At a later date, the University of Maryland (UMD) responded to lARPA’s 
solicitation with a plan for research in identifying social goals pertaining to persuasion. 
UMD subsequently subcontracted University of California at Santa Cruz and the Naval 
Postgraduate School (NPS) to work on the project. Each institution involved will serve as 
a performer team that will interact and contribute to the program via an aggregate system 
based on a service-oriented architecture (SOA). The information generated by each 
performer team will be stored into a core knowledge repository for analysts to examine 
for future events. 

The issue that needs to be addressed involves the design and development of an 

automated system that the Naval Postgraduate School (NPS) performer team will employ. 

The design of a system will describe how the software is to be constructed and is based 

on the requirements set forth by the users, in this case the stakeholders of the SCIL 

program. It is critical that a careful examination of these requirements be conducted and 
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validated by a UMD representative to subsequently provide our performer team with an 
effective automated system to execute their component in this program. The system to be 
developed must be capable of performing the following: 

• Allow for local access for the collection, storage, and modification of the 
data to be forwarded. 

• Allow for remote access to the data. 

• Allow for the transfer of data to the external knowledge repository over 
the Internet. 

B. THE SOLUTION 

In order to address these system requirements, our research focuses on answering 
the following three questions: 

1. What are the requirements for system to be implemented by the NFS 
performer team? 

2. What is the appropriate design of a modular framework to effectively 
manage the natural language assertions in a knowledge base repository 
and the sharing of the knowledge via the World Wide Web? 

3. What is the appropriate Web-service design to allow for multiple users to 
update the knowledge base repository of natural language assertions from 
multiple sites? 

In this thesis, we addressed the first question by generating a software 
requirements specification that makes use of various use cases that reinforce our 
understanding of the system functionality. The specification was validated by a UMD 
stakeholder. After a careful review of the system requirements, we used an object- 
oriented analysis and design approach to address question number two. We developed a 
preliminary design of the system as a whole using various Unified Modeling Language 
(UML) notations. We also analyzed and developed a database schema required for the 
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local storage. Lastly, we implemented a prototype system using a Web Service 
Description Language file (WSDL) and an Extensive Markup Language Schema 
Definition (XSD). 

C. ORGANIZATION 

• Chapter II—Background information on the concepts behind the SCIL 
program, the Assertion Data, SOA, and Web Services. 

• Chapter III—Requirements specification. 

• Chapter IV—System design. 

• Chapter V—Case study using a prototype of the performer team system. 

• Chapter VI—Summary of the thesis and recommendations for future work. 
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II. BACKGROUND 


A. SOCIAL CONTENT IN LANGUAGE 

I. Introduction 

As mentioned in the Introduction, the intent behind the SCIL program is to 
employ appropriate theory and to develop practical technology in order to understand the 
social goals of groups of interest. lARPA identifies three dimensions of the Program to 
be of utmost importance: the social features and activities of the groups; the linguistic 
features that serve as evidence of social goals; and the social science theories that help 
define the social features (lARPA, 2008). The central medium of analysis is the human 
language and how it serves as evidence of social activity. 

The following three domains of knowledge are listed in the BAA as some 
examples in which any organization submitting a proposal can research: 

Social Constructs and Activities of the Group / Members 

• Goals, such as power, solidarity, group supremacy, religious supremacy, 
actions, manipulation strategies (e.g., persuasion, coercion, threats, 
intimidation, oppression, abuse, and exhortation), and recruitment 

Linguistic Features and Their Form, Meaning and Strength 

• Sacred language 

• Conversational patterns (e.g., turn-taking; conversational cues and 

markers) 

Social and Cultural Themes and Institutions 

• Coercion 

• Recruitment 

• Loyalties (e.g., family, government, land, religion) 
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The UMD team will analyze persuasion attempts to contribute to the overall 
program. More specifically, the UMD performer teams will seek to provide information 
to the analysts by using a multidisciplinary approach to analyze the language obtained 
over an online textual-based communication system. Miller defined persuasion as “any 
message that is intended to shape, reinforce, or change the responses of another, or 
others” (Miller, 1980). Since the Internet has quickly developed into a primary tool of 
communication, it has since served as an ideal means for individuals or groups of 
individuals affiliated with terrorist organizations to express their beliefs and to initiate 
persuasive dialog with the intent to either convince others to take some kind of action or 
to accept some proposition or belief. There are many services and massive multi-person 
online environments that facilitate online communication (e.g., Facebook, MySpace, 
Twitter, World of Warcraft), providing a medium over which to influence and persuade 
individuals in such a manner that would negatively affect our national security. 

A key supporting idea in theories of persuasion deals with research in compliance 
gaining. Compliance gaining involves a situation in which one person seeks to convince 
another person to do something for him/her. Marwell and Schmitt identified 16 
compliance-gaining strategies. Their paper on this subject is seminal because the majority 
of research up to that point was concentrated on why people complied with persuasion, 
instead of how they went about complying (Marwell & Schmitt, 1967). Another key 
aspect of persuasion concerns framing effects, which are different from compliance 
gaining in that they are related to the way in which language is used in persuasion as 
opposed to the actual decision process used in persuasive arguments. Framing effects 
focus on the intentional linguistic selection a person makes in order to solicit a certain 
response or choice. 

2. SCIL Architecture 

For UMD to accomplish their work in the analysis of persuasion, they require a 
multidisciplinary approach, which includes disciplines in linguistics, natural language 
processing, and communications working together in order to form an assertion based on 
raw data. The raw data will be communication text found online from various social 
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forums. In the long run, the raw data will be proeessed at the lowest level into an 
automated system that performs the natural language proeessing using artifieial 
intelligenee to generate the assertions and subsequently forward the assertions to the 
knowledge base. For UMD, the assertions will deal with persuasion events. Figure 1 
depiets the SCIL program arehiteeture as intended, whieh demonstrates UMD and other 
notional performer teams. Intelligence analysts will execute queries to the knowledge 
base for information about certain groups of interest without having to go through the raw 
data. With the information at hand they, in turn, would advise higher level decision 
makers. 
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Figure 1. SCIL architecture 


Currently, the UMD team is in the prescheduled Base Period, which consists of 
ongoing discussions about the content of an assertion, the definitions of language use, 
and performing system prototype testing. During this testing period, the system that we 
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will design will allow for local UMD researchers to manually store, manage, and forward 
sample or real assertions into the repository. The next sub-section describes the current 
agreed upon contents of an assertion. 

3. Assertions 

Assertions about groups of interest are what the analysts will query from the 
knowledge base. An assertion is defined as a declaration about something with or without 
facts. One can assert that the sky is green, or even that computers can talk, but without 
any evidence or support those assertions are meaningless. For our purposes, we will 
further define an assertion to be made up of the following three elements: 

a. Claim 

A claim is what the assertion is about. It contains a proposition about 
social phenomena in conjunction with a qualifier that reflects inherent uncertainty. The 
claim is based on and substantiated by language use. For example: “Phillip is a well- 
established leader of the group.” 

b. Evidence 

The evidence serves as the basis from which the claim is derived. 
Evidence is composed of sets of statements about social-linguistic features and/or social- 
cultural phenomena exhibited by the core data. For example: “90% of the topic 
discussions are initiated by John” or “Phillip is often referred to as sir.” 

c. Support 

Support is the rationale for asserting the claim based on the evidence. 
Support is an explanation, contextualization, and framing of the claim via one or more 
context statements. For example: “People who initiate discussions are typically leaders,” 
or “Men that are referred to as ‘sir’ are well respected in their culture.” 

While we do expect that the definitions and concepts behind the generated 
assertions to evolve, our proposed system, along with the system tasked to perform the 
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natural language processing, will serve as a component deployed in a service-oriented 
architecture (SOA). The SOA architecture will utilize Web services communicating 
between UMD teams and the SCIL program repository. Section B describes the 
background of SOA and section C will provide information on Web services. 

B. SERVICE-ORIENTED ARCHITECTURE 

I. SOA Introduction 

The purpose behind SOA is to allow for an enterprise to efficiently build 
applications that provide a service or processes to users while overcoming distributed 
computing challenges (Papazoglou & van den Heuvel, 2007). The impetus behind SOA 
has been the limited and complex nature of an organization’s legacy IT architecture and 
its inability to implement solutions in support evolving business goals. More so, it is the 
lack of integration between an organization’s internal IT systems and their business 
processes, business partners, and customers that is the driving force for change from the 
current system architecture to one that is service-oriented (Marks & Bell, 2006). 

SOA is a term that represents a model or a design in which automation logic, 
which seeks to provide a solution to a given concern, is decomposed into smaller, self- 
sufficient, and distinct units of logic each of which contribute to the completion of the 
overall function (Erl, 2005). These decomposed units of logic, known as services, can 
range in size and scope. SOA, in and of itself, is not a technology. The key behind the 
SOA concept is that the services must be self sufficient. By avoiding inter-dependency, 
each individual unit can evolve on its own (Erl, 2005). The basic method in which an 
SOA looks to provide benefit is through the separation of concerns, decomposition if you 
will, to allow for smaller entities to complete their respective functions in order solve the 
overall concern. 

The theory behind the separation of concerns, which Dijkstra references in his 
manuscript EWD 447: On the role of scientific thought, claims that there are benefits in 
decomposing a large problem into a set of smaller individual concerns where each 
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individual concern is addressed by a unit of logic (Dijkstra, 1982, pp.60-66). Object- 
oriented programming, as an example, implements this concept with its use of objects, 
classes and components. 

Ideally, the services in a SOA should not only be aware of other services but be 
able to communicate with them. The services utilize what is called a service description 
to identify, locate, and manage the communication between services. The communication 
between the services takes place via a framework called messaging. Each message while 
underway from service to service is also self-sufficient and not dependent on anything 
but itself (Erl, 2005). 

So far, what has been described is the basic architecture of what SOA is about. 
Eigure 2 provides a visual representation of the basic architecture thus far. 



Eigure 2. SOA architecture 


Erl provides us with a simple analogy of the concept behind SOA, comparing it to 
a business community. Every city has some business community that consists of entities 
ranging in size from a Wal-Mart to a local mom and pop store. These businesses provide 
services to us as consumers, similar to how the units of logic (services) from a system 
perform a function and, if you take the business community as a whole, it seeks to solve a 
particular demand, much like how the automation logic provides a solution for an overall 
concern. The services still have certain established regulations that must be followed. In 
SOA, these regulations are the principles that drive service-orientation (Erl, 2005). 
Continuing with the business community analogy, the analogous regulations in place 
could consist of a common currency that must be used for a transaction or even a 
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common language that must be spoken. The services follow a set of common service- 
orientation principles through a process. 

2. Principles of SOA 

The following are commonly accepted principles of service-orientation as 
described by Thomas Erl: 

a. Services Are Reusable 

Reusability benefits by reducing the need for future development efforts. 
An analogy would be similar to how the Department of Motor Vehicles (DMV) services 
all requestors for a driver’s license, but an even more reusable service would be a DMV 
that distributed licenses to users of all types of vehicles (ground, rail, aviation, boat, etc.). 

b. Services Share a Formal Contract 

Similar in concept to how a consumer would need to fill out an application 
for the vehicle license mentioned above, the contract defines the service, the 
operations/activities, and the messaging that are required to consume the service. 

c. Services Are Loosely Coupled 

Loose coupling facilitates agility. The factors that influence change in an 
IT environment are external, and so it is important that the underlying logic behind the 
individual services be independent. After we have waited in line, filled out our 
application, and taken the test at the DMV, the responsibility is on the DMV to process 
and provide us with the license. 

d. Services Abstract Away Underlying Logic 

The details (underlying logic) that make the service work are hidden, and 
of no concern to the user as long as the service works. Not many people know or care 
exactly what the DMV does in order to process their request for a license. 
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e. Services Are Composable 

Composable means that services can have subservices. A service-oriented 
process is one that has a parent process in which it calls its underlying services to perform 
a subfunction. This principle reinforces reusability. The local law enforcement agency 
would require the use of the new DMV to license their drivers as well. 

/. Services Are Autonomous 

Autonomy allows for self-governance of all its processing, which 
subsequently allows for a service that is free from any dependencies that would restrain 
its deployment and evolution (Erl, 2005). Let us assume that the new DMV requires a 
background check on people applying for a license. The DMV normally delegates that 
task to another agency, and is dependent on their results. If the DMV were to perform its 
own background check, this independence would allow for the DMV to evolve its 
services without being held back by a dependent functionality. 

g. Services Are Stateless 

If a service is tied up by managing information, it reduces its own ability 
to receive other requests from other requestors. A stateless service promotes reusability 
and scalability by forwarding the message received and forgetting that it ever had the 
message, let alone what it was about. A services state is dependent on how well-designed 
the indiviual operations are, and how they function. The self-sufficient messages 
mentioned previously support statelessness. After completing the processing for an 
applicant’s license, the details behind the application are saved in a database and there is 
no reason for the DMV to linger on your request. By doing so, it would inhibit the ability 
to service other applicants. 


12 



h. Services Are Discoverable 

Discoverability prevents redundancy in service development. A discovery 
mechanism should be in place that enables potential clients who need your service to 
locate and consume it. The DMV information (location, phone number, etc.) can be 
found in the yellow pages, the Internet, or even signage on the highway, which is how we 
know to go there to begin with. 

3. Benefits of Using SOA 

We have vaguely touched on the benefits of using a SOA for any particular 
organization. Not all organizations require a change or, specifically, a shift in 
architecture, but for those organizations that are finding it costly to make changes to their 
current IT structure in response to a dynamic business environment, an SOA solution 
may be worth exploring. SOA provides developers with a means to overcome many 
distributed enterprise computing challenges, such as application integration, transaction 
management, and security policy enforcement, while allowing the concurrent use of 
multiple platforms and protocols and leveraging numerous access devices and legacy 
systems (Alonso et ah, 2004). 

Depending on how it is used, the benefits of SOA relate to the aforementioned 
principles and include the following: the costs of integrating your applications will be 
reduced, your returns on investment will increase due to the reusability principle, a 
reduced processing overhead and reduced skill-set requirements are experienced due to 
the services being composable, the need to replace legacy systems is reduced, which in 
turn saves money, the use of a standardized language like Extensive Markup Language 
(XML) reduces the cost and efforts of application development, and the costs involved in 
responding to changes via external sources are also reduced (Erl, 2005). 
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c. 


WEB SERVICES 


A Web Service (WS) is defined by the World Wide Web Consortium (W3C) as: 

A software system designed to support interoperable machine-to-machine 
interaction over a network. It has an interface described in a machine- 
processable format (specifically WSDL). Other systems interact with the 
Web service in a manner prescribed by its description using SOAP 
messages, typically conveyed using HTTP with an XML serialization in 
conjunction with other Web-related standards. (W3C, 2004) 

Basically, a WS is a method of implementing a distributed system, which allows for 
objects on one computer to interact with those of another computer over the Internet. 
There are currently two prominent models used for creating Web Services: the 
Representational State Transfer (REST) model and the SOAP-based model. 

1. RESTful Web Services 

RESTful WS allow for access to resources on a network referenced via a Uniform 
Resource Eocator (URE). REST uses HTTP as the primary transportation protocol to 
support the execution of one of the four methods: GET, PUT, DEEETE, and POST. 
REST services have limited support, in that REST has no standardization, few toolkits, 
and little by means of software library support. Message exchange can be performed in 
various formats (e.g., XME, HTME). Eigure 3 shows an example request and associated 
response for a RESTful service. 


Request Response 


HTTP 1 1 200 OK. 

Content-Type: text .xml, chai set^utf-8 
Content-Lengtli nun 

GET Stock-Price Tlth 1 HTTP 1 1 

Ho.st: cxample oia version-'I O"*;' > 

Accept text xml s Quote xmlns:s’="http exanijileoi g stock- 

Accei)t-Chai! 5 et utl-8 saxice" 

<s:Tickei Symbol •IBM< s Ticket Symbol 
' s StockPiice 45.25 siStockPiice ■ 

• s:Quote • 


Eigure 3. REST Web service request / response (Erom Spies, 2008) 
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SOAP-Based Web Services 


SOAP is the accepted standard method of communication between computers 
over the Internet that specifically uses XML to represent the information passed. SOAP is 
supported with toolkits and various software libraries. The earliest version of SOAP, 
version 1.1, was adopted by the W3C after its submittal in May of 2000. SOAP, which 
once stood for Simple Object Access Protocol, is currently in version 1.2 and is based on 
messages taking the form of documents. The encoding behind the request and response 
operations of SOAP WS is in XML format and the network transportation protocol can 
be by any means (e.g., IBM MQSeries, MSMQ, or SMTP) but the most common 
protocol is HTTP. For this research, we will focus on SOAP-based Web Services. Figure 
4 shows an example request and associated response for a SOAP-based service. 


Request 

Response 

GET/StockPnceHTTP/l.l 

HTTP/l .l 200 OK 

Host: example.org 

Content-Type: application/soap+xml. 

Content-Type: application/soap+xml, charset=utf-8 

charset=utf-8 

Content-Length: nnn 

Content-Length: nnn 

<?xml version—’1.0" ?> 

<?xml version—'1.0"?> 

<env:Envelope xmlns:env = “http: //www.wS.org/ 2003/05/ 

<env;Envelope xmlns: env—'http;//www.w3.org/2003/05/soap-envelope " 

soap-envelope" 

xmlns: s="http://www. example, org/stock-service" > 

xmlns:s—'http://www.example.org/stock.-service"> 

<env:Body> 

<env:Body> 

<s:GetStockQuoteResponse> 

<s:GetStockQuote> 

<s:StockPrice>45.25</s:StockPnce> 

<s:TickerSymbol>IBM</s:TickerSymbol> 

</s:GetStockQuoteResponse> 

</s: GetStockQuote> 

</env:Body> 

</env:Body> 

</env;Envelope> 

</env:Envelope> 



Figure 4. SOAP Web service request / response (From Spies, 2008) 


3. Web Service Components 

As mentioned previously, SOA consists of units of logic known as services that 
require a means either to locate other services or to advertise services. SOA also supports 
a means of communication that would enable interaction between services. In this 
section, we will elaborate more on each component that makes up a WS. 
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a. Services 

A WS can be classified as being temporary or permanent, depending on 
the function that it assumes during runtime or its application logic. The basic service 
roles a service plays are that of a provider, intermediary, and a requestor (Erl, 2005). In 
the requestor role, the service will initiate the transmission of a message requesting a 
particular service of which the provider was designed to execute. The provider will 
execute the request and respond to the requestor. As an intermediary, the service will 
process a message, performing its own functionality, and forward the request to its 
service provider. Some functions an intermediary service can perform are authentication 
services, auditing services, and management services (Irani, 2010). 

Services based on the nature of the application logic in which the service 
is intended to perform are classified as service models. For example, a service can be of a 
Business type (e.g.. Accounts Payable Service) that executes one of many operations 
required by an organization, a Utility type (e.g.. Internal Policy Service) that is 
completely reusable and non-application specific, or a Controller type that would be 
responsible for the coordinated functionality of all of the services within an organization 
(Erl, 2005). 


b. Description 

In order for services to interact, they first need to be aware of each other. 
Specifically, a provider needs a formal description of its services. The description acts as 
a contract with clients who request the provider’s service. A W3C standardized WSDE 
document serves this purpose. WSDE is defined as: 

An XME format for describing network services as a set of endpoints 
operating on messages containing either document-oriented or procedure- 
oriented information. The operations and messages are described 
abstractly, and then bound to a concrete network protocol and message 
format to define an endpoint. (W3C, 2001) 
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The WSDL file is also written in XML and describes the data that will be 
passed and the method that passes it regardless of the programming language used. This 
means that a service written in Python can be consumed by client created in Java. 

Although a WSDL is subdivided into several sections, it is generally 
composed of two key components: an abstract interface description (i.e., operations, 
operation parameters, and abstract data types) and a concrete implementation description 
(i.e., a network address, a protocol, and concrete data structures; Zimmermann, 
Tomlinson, & Peuser, 2003), the latter of which provides the means to actually invoke 
the service. Let us briefly look at the main elements found in a standard .wsdl file. The 
text and sub-tags within a .wsdl file are encapsulated inside of a <definitions> element 
and from top to bottom the five main elements within are: <types>, <messages>, 
<portTypes>, <binding>, and the <service>. 

• <types> —This element includes the abstract information set using an 
XML Schema that defines the data types used in the communication 
process between the service provider and the requestor. If there are an 
excessive number of data types described, the schema can be imported 
into this section as a separate document. 

• <messages> —The message element defines the abstract content of the 
messages to be communicated. The content includes the name of the 
message part (what the message is called), the element attribute that refers 
to the XML schema (what the message is), and the type (the type of data it 
holds). 

• <portTypes> —The port type element identifies and describes a specific 
service interface. It is a named-set of abstract operations and their abstract 
messages that come in two varieties, input and output. The operations are 
made up of the messages described in the messages element. 

• <binding>— The purpose of the binding element is to connect the abstract 
port type description to a concrete service implementation. The protocol 
details to send the messages are defined here. 
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• <service> —The service element, which is also known as the endpoint, 

specifies where and how to send the information. The service element 
works with the binding element by connecting a port type to a particular 
port defined within the service element. 

Figures 5 and 6 are excerpts from two WSDL documents entitled 
stepGovServices_12.wsdl and stepPortTypes_12.wsdl (Tong, 2009). These files are 
referenced again in Chapter IV. 


XMl.Schenij is iniporteil. 


Name nf \ \ II. Schein j 


<ws(JI definitions> 

<ws(JI types> 

<xs schema> 

<X8 import r>amesp»c»="http //www larpa gov/SCIL/STEP_Schema" schemaLocatioo="stepSchema_1 1 xscl7> 
</xs schefna> 

<Msdl typ«s> 

o*sdl message name-'KbUpda(eRequest'> 

. <wsdl part name="updateReque8t' »lement=’stepd KbUpdateRequestMsgParfV> 

</Msdl message > 

'Cwsdt message name=''KbUpdateResponse’> 

<ws<fl part n8me="updateResponse' element="s1epd KbUpd3teRespooseMsgPart‘''> 

</wsdl message> Message 

<ws(9 message name=''SlalusReportRequesl~> eieinenis 

; <wsdl part narT(e="statusRequest" elemeni= stepd StatusReportRequestMsgPart"/> 

</wsdl message > 

<wsdl message name-"StalusReportResponse"> 

cwsdl part name^'statusResponse" elemenl-'stepd StatusReportResponseMsgPart7'> 

</wsdl message > 

<wsdl portType name=’'KbUpdatePortType"> 

<wsdl operation name=‘'KbUpdate'> 

<wsdl input me8sage=' steps KbUpdateRequest"/> 

: <wsd) output message^'steps KbUpdateResponse'V> 

: </vrsdl opeiation> 

</wsdl portType> 

<wsdl portType name="StatusReportPortType"> 

: <wsdl operation name="StatusReport"> 

<wsdl input message=’'steps StatusReportReqoesf7> 

<wsdl output mess8ge="step8 StatusReportRe8ponse"/> 

' <Msdl operation > 

</wsdl portType > 


T’ort Types 


Figure 5. WSDL, abstract interface description 
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<wadi iHoding n>iT<e=' KBUpda(«SaapBtfiding' type- steps KbUpdalePoftType'> 

csoapi? bindmg sl^'te«~dacum«nt' transpoi1«"trttp //schemas xmlsoap org/soapihttp'' > 
swsdl operation nam9=: KbUpdate" ' 

<scap12 opecalioo soapAction=’kbUp(iate' soapAcliooReqi*f»d= 'tiue‘ sly1e='docurnenf/> 

<wsd input > 

i ’ <saap12 body u$e’''litefar7> 

</wsdl input> 
cwsdl output> 

; <soap12 body uie^'litefal’ 

<''wsdl oiitput> 

<<'wsdl operation^ 

</wsdl binding> ^ Biiuling 

binding naine= "StalusRepoitSoapBinding'' typ«=’ steps StalusReportPoitType~> olcuicnts 

<soap12 biiiifcng slvte-'documtnl' tianspod-'lillp //schemas xmlsoap Ofg/soapiTitlp'/> 

<ws<» operation name= StatusReporl ’ 

<saap12 operation 6oaoAction=‘statusReporf saapAct'OnReqw'ed= true' style- ■document'/> 
ciesdl input* 

xsoapi? body use-'liteiar > 

= 'wsdl input* 


<wsdl output* 

<sosp12 body use- literal'.'* 

</wsdl output* 

: Ciiwsdl operation* 

</wsift biniing* 

<wsd serace name='UMD_KbUpdate"> 

: rwsi* port name-“KbUpd3lePortTyp«“ hmdng -’steps KBUpdateSoapBuiding'* 
<ioap12 address location»'1ntp //localhost 8080/Uh<OSCIL'V(dO_Kb(Jpd3te’'/> 
ciWsdl port* 

</wsdl servKe* 

OMSdi serace naine^’UMD SlatusRepoit’> 

xwsif port nBni»»"StatusReportPo*tType' bin<bng= steps StatusRepoilSoapBin*ng''* 
• <5oap12 address locations 'http//localhost 8080/Uh®SCILA/fi1D_StatusRepo«f/> 

. Cj’wsdl port* 

CiVisdl senace* 

</wsdl detiiKtions* 


Service 

clemenrs 


Figure 6. WSDL, concrete implementation description 


c. XML Schema (XSD) 

An XSD is a model document that defines the structure of a separate XML 
document. The XML document will contain a reference to the XSD that defines its 
structure, much like how the schema is imported to support the WSDL document in 
Figure 5. The schema’s syntax is entirely in XML, and it serves to validate the XML 
document’s adherence to the schema’s structure. An XSD can contain several subordinate 
element types, similar to a WSDL, and tends to be very complex. However, some of the 
basic elements that you will find in an XSD are: <elements>, <attributes>, 
<simpleType>, and <complexType>; all of which serve to define the text data as strings, 
integers, dateTime, or data types. Figures 7 and 8 are excerpts from an XSD named 
stepSchema_12.xsd (Tong, 2009). 
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<xs element name="KbUpdateRequestMsgP^ "> 
<xs annotation> 

<X8 complexType> 

<xs sequence> 

<xs element name='Metad3ta'*> 

<xs complexType> 

<xs sequef»ce> 


This element consists of two inuin 
elements Metadata and Par/oad 


Metadaur . CojLsistj? oi^Message ID 
tJial IS siniiji and a Tetnn ID llial is 
defined fiutliei along ui the xsd 


i <xs element name="Messa 9 eld’ type='xs stnng'> 

I I <xs annotation> 
i </xs element> 

j <xs element name=Te3mlcr type=”stepd Teamld"> 

: I <xs annotation> 
i </xs element > 

</x8 sequence> 
i </xs complexType> 

</X8:element> 

<xs element name="Payload'‘> 

I <xs complexType> 

<xs choK:e> 

j <X8 element name=’AssertionAddBundle" type='stepd AssertionAddBundle"/> 
i <xs element name=‘AssertionReptace6undle* type='stepd AssertionReptace8undle7> 
j <X8 element name="AssertionDeleteBondle’ type=*stepd AssertionDeleteBundle7> 

</xschoK:e> 

Pavlomi . Consists of an option of one of lliree 
Bnndlcs: AsscitiojiAdd, AssertionReplace. and 
AsseilionDeiele of wliicli aie also ilefineil within 


j </xs complexType> 
<yx8 element> 

</x8 sequence> 

</x8 complexType> 

</xs element> 


the xsd 


Figure 7. XSD I 
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<xt *imp»«Typ» nani#='T»amkr> 

<xs annotalion> 

i <X5 documen1a(io»i>Type tha( enumerates 
</x$ annolation> 

<x$ testnction batt-'x$ *tnng"> 

<xs enumefaixm value='ALB'/> 

; <xs enumeration valuen-ASU V.-- 
: <xt enumeration value- 'B8N'V> 

I <x$ enumeration valiierrXO(.'''> 

; <xs enumeration value="LCC’/> 

<X5 enumeration value= SRIVs 
<xs enumeration valuer UMDVx 
<x$ enumeration value= 'UWA7> 

I <xs enumeration vBlue=’GO\r/> 

«yxs leslnctionii 
</x$ iimpteType> 


the Performer team IDs <yxs <locumentation> 


I 


Team ID is ic^tnctcdto be one of tJie stcveial t>'pcE! of 

kl.'i lisletL tltiit ;iie s^nllg^’ 


<xs complexType iiame^As5eitianA<i<l6iin0le'> 
cxs 4nnotation> 

<X9 se^u«nce> 

j corip(exTy^> 

<xs Mquencc> 

elemetnt r ?ne= A589ftiooCounl *• 
! <xi «fin()(iitiOn> 

•5X8 8impl®Typ«> 


AsserliitnAtItIBunille contains a 
set of siib-elements as well 
uicliKliug Payload wlucli is also 
(lerinedsoniewlieieiii the xsil 


I 


I 


<x» lestnction oese- xs integers 
( ^x* mmlnclwrit »aui»"1''r> 

' I oxi resinctxin> 

<Iks simpl«Tvpe> 

<h(8 elem«r«> 

<.‘xt sequenco 
</xf comploxType> 

</xs element > 

<X6 nlemnix n»fne='Pa\Hn»d’> 

<xi complexTypex 
xxs sflgjoncox 

<X8 element name= Assertion" t>oe="8tepd KOAssertion' TaxOccurs="unbowioeo' x 

I <xs mmiXatiDnx 

</x8 elemeixx 
I </xs sequftfKiex 
I sTxs comploxTypex 
<.'xt elementx 
; «ix» seguencex 
<iXs complexTypex 


Figure 8. XSD II 


d. Messaging 

The communication protocol shared between services is the standard 
HTTP application layer used by clients and servers over the Internet. However, since the 
communication between services is message-based, the framework used should be 
standardized, flexible, and highly extensible (Erl, 2005). The SOAP messaging 
framework meets these requirements. A SOAP message contains the following elements: 
<Envelope>, <Header>, and <Body>. 

• <Envelope> —The header is a mandatory element that acts as a container 

for the header and body elements. This element defines itself (an XML 
document) as a SOAP message. 
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• <Header> —The header element is optional and provides a means to pass 
any kind of additional processing or control information to recipients of 
the message. 

• <Body> —The body is mandatory in that it holds the actual SOAP 
message intended for the service provider. 

Figure 9 demonstrates a basic example of a client service requesting a 
connection identification number by sending a SOAP message containing a user name 
and password. The service provider responds to the requestor with the connection 
number. 


Ede Eroject 

JSML 

DTD/5<h«m« 

Schctoe design 

XSl/XQuefy 

Authentic Q6 

Com-ert yitvi 

B0 

a 


#4 ^ 


^ ^ dp 



<S0AP.6NV Erivstop* T'r.^; r tfiV='hnp /schemas xmlsoap ofg^soapt'envslope 
.rir . ' :.i='hnp//imiw w3 or9/2001/>MLSchema-instance' xi-i-' ■- »<.()-'Wip/hwwv w3 c 
<SOAP€tJV 8o<»y> 

<m connect • r . ni mr'um exist' > 

<m usedd>adnnin</m use(ld> 

<m p3ssword>p3ss«vord<.'m pa$sword> 

■ c./m connect > 

</SOAP-ENV 8ody> 

</SOAP EMV Efh«lope> 



ac 

n 


1 

- 

0" encod y-w 

2 

<soapenv Envelope xr'lr-; soap-'n/="http //schemas xmlsoap otg/soafVenve 


http //wwftv w3 of9/2001/XMLSchema-tnstance'> 

3 

<soapenv Body> 

4 


<connectResponse ’ : tns="um exist' > 

5 


<connectRetum>7135854</connectRotum> 

6 


</connectResponse> 

7 

</soapenv 8ody> 

8 

9 

<,/soapenv Envelope> 


Figure 9. SOAP message 
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D. SUMMARY 


This chapter began with an overview of the SCIL program intended to identify the 
social goals of a group of interest and its members by analyzing language features. UMD 
has proposed a research supporting the program that involves addressing the social 
phenomenon of persuasion. UMD will conduct a multidisciplinary approach to analyze 
the language and its use to determine if the intent to persuade is present. In order to make 
this happen, online text dialogue needs to be collected and analyzed to create assertions 
identifying persuasion attempts. These assertions must be processed by a system capable 
of performing the following: collect, modify, and locally store the data, allow for remote 
access to the data, and allow for the transfer of data to the external knowledge base 
repository over the Internet. We also covered some of the background on SOA and its 
benefits and we finished the chapter with a discussion on Web Services along with their 
common protocols (i.e., WSDL, XSD, SOAP). In Chapter III, we will address the key 
features and requirements necessary for the development of our proposed system. 
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III. SYSTEM REQUIREMENTS SPECIEICATION (SRS) 


A. OVERVIEW 

A software requirement is defined as a “software capability that must be met or 
possessed by a system or system component to satisfy a contract, standard, specification, 
or other formally imposed documentation” (Leffingwell & Widrig, 2003). The 
methodology used to derive the following requirements for our proposed system were 
based on a face to face interview with a SCIL representative and an agreed upon set of 
use cases to describe the general system functionality. 

1. Purpose 

The purpose for this SRS is to determine the functional and nonfunctional 
requirements necessary to effectively store, process, and transfer assertion data generated 
by the local UMD performer team in support of the SCIL program. 

2. System Perspective 

This software is a new and self-contained product that is a separate component of 
a larger system design that includes other performer clients and services from various 
learning institutions and a central application server that provides a WS endpoint. Other 
performer systems will interact with the application server in the same way. 

3. System Features and Domain Model 

The major features of this system include two Web services: one that will display 
a local service status when queried by an external client; and another that will allow for 
an external client to retrieve assertion data, a WS client that will be capable of updating 
the external knowledge base, a software application that will be used to manage the 
assertion data and services, and a database used to store the data. All of the 
aforementioned features and interfaces will be written in or interact with the JAVA 
programming language. 
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Figure 10 is a domain model, which displays a visual perspective of the concepts 
relative to the proposed system. The local users will use the system to create assertions to 
be stored locally. The assertion text is composed of a claim, evidence, and support data. 
The assertion text combined with a local system-generated assertion ID (local ID), and 
lARPA’s external system-generated assertion ID (external ID), and a date and time group 
(DTG) form a knowledge base assertion that is stored locally. 

Our system will deploy two Web services: ExplanationGetWS and 
StatusReportWS. The ExplanationGetWS will allow for clients to retrieve assertion data 
from the local system. Our system will also execute one WS client: KbUpdate client. 
KbUpdate client will interact with the external system’s WS to transfer, replace, or delete 
assertion data. Our KbUpdate client and ExplanationGetWS will have a status associated 
with them that will be returned in response to queries to the StatusReportWS. The core 
operations will be explained in more detail in Chapter IV. Both Web services will be 
deployed on an application server that will allow for their consumption by the external 
system. The domain model also depicts a DataPush client. The purpose behind the 
DataPush client has not been agreed on by the UMD stakeholders at this time; therefore, 
aside from its place in the domain model, this research will not include the DataPush 
functionality. 
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Figure 10. Domain model 


4. Intended Audience 

This SRS is intended to be read by the local users and project managers who 
represent the UMD team in support of SCIL. 

B. FUNCTIONAL REQUIREMENTS 

This section begins the description of the system features utilizing several use 
cases that serve as functional requirements. The use cases are scenario-driven, meant to 
provide us with both an outside-in view of the system functionality, and a critical tool in 
the analysis process. Figure 11 is a use-case diagram, which introduces the system actors 
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and their respective interactions with the system. The elements listed under UMD System 
represent the individual use cases, and will be explained in more detail. As a reminder, 
the local users will be replaced by an automated system that creates the assertion from the 
input of raw data in the future. 

Following each use case, we have provided a system sequence diagram (SSD). An 
SSD is “a picture that shows, for one particular scenario of a use case, the events that 
external actors generate, their order and inter-system events” (Larman, 2005). The point 
behind the SSD is to identify the particular events that will transpire during execution 
giving us a clearer picture of the system behavior. 



Figure 11. Use case diagram 
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1 . 


Local User Stores Assertion 


Table 1. Local user stores assertion 


Primary actor 


Local user 

Stakeholders and 

• 

Local user wants to store the assertion in to the local 

interest 


database. 


• 

External user needs the assertion to be accessible. 

Entry conditions 

• 

The local user workstation needs to be operational. 


• 

The local user has already logged in. 


• 

The local user can access the assertion text via the 

local workstation. 

Exit conditions 

• 

The assertion has been assigned an external ID. 


• 

The assertion is stored within the local database. 

Main scenario 

1. 

The system displays a menu option, which includes the 

option to store the assertion. 


2. 

Local user selects the option to store assertion. 


3. 

The system displays an interface that allows for the 

manual entry of the data along with the option to store 

the assertion. 


4. 

Local user manually enters the assertion data into 

provided text fields. 


5. 

The local user selects the option to store. 


6. 

The system generates an local ID for the assertion. 


7. 

The system generates the DTG for this instance. 


8. 

The system stores the assertion, respective DTG, and 

local ID into the local database. 


9. 

The system displays the local ID to the user along 

with a message stating that the operation is complete. 

• The User repeats steps 2-9 until complete 
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10. The local user logs off of the workstation. 

Extensions 

*a. Workstation System failure: 

1. The local user restarts the system and logs in. 

2. The system assumes its state prior to step 1 in the 

main scenario. 

3. The local user re-attempts the storing process 

4a. Invalid input: 

1. The system displays an “invalid input error” message 

stating that the data entered was incorrect. 

2. The system returns to the state at step 3 in the main 

scenario. 


Local User Stores Assertion 
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Figure 12. Store assertion SSD 
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2 . 


Local User Transfers Assertion to Knowledge Base 


Table 2. Local user transfers assertion to knowledge base 


Primary actor 


Local user 

Stakeholders and 

• 

Local user wants to transfer an assertion from the local 

interest 


database to the external system/database. 


• 

External system stores the assertions 

Entry conditions 

• 

The assertion data has been previously stored within 

the local database. 


• 

The assertion data is assigned a local ID. 


• 

The local and external systems are operational. 


• 

The local user is logged in the system and is on the 

main menu. 

Exit conditions 

• 

The assertion has been successfully transferred from 

the local database to the external database. 


• 

An external ID is returned to the local user and stored 

in the local database. 

Main scenario 

1. 

The system displays a menu option, which includes the 

option to transfer assertion data. 


2. 

The local user selects the option to transfer an assertion. 


3. 

The system displays an interface that allows the user to 

select the assertion(s) that will be transferred 


4. 

The local user selects the assertion(s) and then selects 

submit. 


5. 

The system initiates a query to the local database for 

the assertion data using the local ID as reference. 


6. 

The system makes a copy of the assertion data. 


7. 

The system executes the KbUpdate client system by 

sending the copied data over the internet to the 
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external system. 

8. The external system redirects the data to the external 

knowledge base for storage. 

9. The external system returns an assertion external ID(s) 

to the sender. 

10. The local system receives and displays the external 

ID(s) to the local user. 

11. The system stores the external ID in the local database. 

12. The system returns the local user back to the main 

menu. 

• The User repeats steps 2-12 until complete. 

13. The local user logs off. 

Extensions 

4a. Invalid identification number: 

1. The system displays an error message stating that the 

identification number entered was mal-formed or 

non-existent. 

2. The system returns to the state at step 3 in the main 

scenario 

7a. Network failure before the assertion reaches the 

external database: 

1. The local system displays an error message stating 

that a connection was not completed. 

2. The system returns to the state at step 6 in the main 

scenario prior to the transfer attempt. 

9a. Network failure after the transfer and before the 

return of the external ID. 

1. The system displays an error message stating the 

network condition. 

2. The system returns to the state at step 6 in the main 

scenario prior to the transfer attempt. 
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User Transfers Assertion Scenario 



Figure 13. User transfers assertion SSD 


3. Local User Replaces Assertion in the External System 
Table 3. Local user replaces assertion 


Primary actor 

Local user 

Stakeholders and 

interest: 

• Local user wants to replace an existing assertion in the 

external database with one from the local database. 

• External System stores assertions. 

Entry 

conditions: 

• The assertion data has been previously stored within 

the local database. 
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• The assertion data is assigned a local ID. 

• The assertion to be replaced has been assigned an 

external ID and that ID has been stored in the local 

database. 

• The local and external systems are operational. 

• The local user is logged in the system and is on the 

main menu. 

Exit conditions: 

• The old assertion has been successfully replaced by the 

new assertion. 

• An external ID is returned to the local user and stored 

in the local database. 

Main scenario: 

1. The system displays a menu option, which includes the 

option to replace an existing assertion in the external 

database. 

2. The local user selects the option to replace an 

assertion. 

3. The system displays an interface that allows the user to 

select the assertion that will replace the assertion in the 

external database. 

4. The local user selects the assertion. 

5. The system displays an interface that allows the user to 

select the assertion that will be replaced. 

6. The user selects submit. 

7. The system initiates a query to the local database for 

the assertion data using the local ID as reference. 

8. The system makes a copy of the assertion data. 

9. The system executes the KbUpdate client by sending 

the copied data and the external ID of the assertion to 

be replaced over the internet to the external system. 

10. The external system redirects the data to the external 
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database and replaces the assertion referenced by the 

external ID storage with the new assertion. 

11. The external system returns a new assertion external 

ID assigned to that assertion to the local system. 

12. The local system receives and displays the external ID 

and a message to the local user indicating the 

operation is complete. 

13. The system stores the new external ID in the local 

database. 

14. The system returns the local user back to the main 

menu. 

• The User repeats steps 2-14 until complete. 

15. The local user logs off. 

Extensions 

4a. Invalid identification number: 

1. The system displays an error message stating that the 

identification number entered was mal-formed or 

non-existent. 

2. The system returns to the state at step 3 in the main 

scenario. 

9a. Network failure before the transfer takes place: 

1. The local system displays an error message stating 

that a connection was not completed. 

2. The system returns to the state at step 6 in the main 

scenario prior to the transfer attempt. 

11a. Network failure after the transfer and before the 

return of the new identification number: 

1. The system displays an error message stating the 

network condition. 

2. The system returns to the state at step 6 in the main 

scenario prior to the transfer attempt. 
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User Replaces Assertion Scenario 
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Figure 14. User replaees assertion SSD 


4. Local User Edits Assertion in Local Databas 
Table 4. Local user edits assertions 


Primary actor 

Local user 

Stakeholders and 

interest: 

• Local user wants to ensure that the data stored in the 

local database is updated correctly. 

Entry 

conditions: 

• The assertion data has been previously stored within 

the local database. 

• The assertion data is assigned a unique identification 
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number. 


• The loeal system is operational. 

• The local user is logged in to the work station. 


Exit conditions: 

• The data within the local database has been updated 

successfully. 

Main scenario: 

1. The system displays a menu option, which includes the 

option to edit a locally stored assertion. 

2. The local user selects the option to edit assertion. 

3. The system displays a prompt for the user to enter an 

assertion local ID. 

4. The local user enters the local ID. 

5. The system retrieves a copy of the assertion data 

displayed in an interface containing text fields that are 

populated with the current data and are capable of 

being changed. 

6. Local user edits the data through the interface and 

selects the option to save. 

7. The system reassigns the original assertion local ID to 

this instance. 

8. The system generates a new DTG for this instance. 

9. The system inserts the new data, DTG, and the 

reassigned local ID into the local database. 

10. The system displays to the user the local ID and a 

message stating that the update is complete. 

• The user repeats steps 2-10 until complete. 

11. The local user logs off the workstation. 

Extensions 

4a. Invalid identification number: 

1. The system displays an error message stating that the 

identification number entered was mal-formed or 

non-existent. 
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2. The system returns to the state at step 3 in the main 


scenario. 


6a. Invalid input: 


1. The system displays an “invalid input error” message 


stating that the data entered was incorrect. 


2. The system returns to the state at step 5 in the main 


scenario with the original assertion data remains 

unchanged. 


Local User Edits Assertion Scenario 
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Figure 15. Local user edits assertion SSD 
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5 . 


External User Queries ExplanationGetWS 


Table 5. External user queries ExplanationGetWS 


Primary actor 


External user 

Stakeholders and 

• 

The external user needs information from the local 

interest: 


database. 


• 

The local database has the assertion that is being 

requested. 

Entry 

• 

The assertion has been previously stored in the 

conditions: 


external database. 


• 

The assertion is currently stored in the local database. 


• 

The assertion has been assigned an external ID. 


• 

The local service is operational. 


• 

The external user has already provided his/her 

appropriate authentication and has logged in to the 

external system. 

Exit conditions: 

• 

The assertion has been successfully retrieved from the 

local system by the external user. 

Main scenario: 

1. 

The external user (client) submits a request for 

assertion data. 


2. 

The ExplanationGetWS receives the request, which 

includes the external ID of the assertion to be 

retrieved. 


3. 

Using the external ID as a reference, the local service 

selects the respective data from the local database. 


4. 

The data is returned to the external user via the 

internet. 


5. 

The local service returns to the state before the initial 

query. 
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• 

The external user repeats steps 1-5 until complete. 

Extensions 

la. 

Network connection not available: 


1. 

If the network connection is inoperable the external 

user is presented with an error. 


lb. 

Invalid identification number: 


1. 

The service interface displays an error message 

stating that the identification number entered was 

mal-formed or non-existent. 


2. 

The service interface returns to step #1 in the main 

scenario. 
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Figure 16. External user queries ExplanationGetWS SSD 
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6 . 


External User Queries StatusReportWS 


Table 6. External user queries StatusReportWS 


Primary actor 

External user 

Stakeholders and 

interest: 

• The external user wants to verify the status of the local 

system capabilities. 

Entry 

conditions: 

• StatusReportWS is operational. 

• The local capabilities have been assigned a status. 

• The external user provided the appropriate 

authentication. 

Exit conditions: 

• The external user successfully receives the statuses. 

Main scenario: 

1. The external user, acting as the client, submits a 

request to StatusReportWS. 

2. The local service receives the request from the external 

user. 

3. The local service retrieves the operational status. 

4. The operations status is returned to the external user 

via the internet. 

5. The local system returns to the state prior to the initial 

query. 

• The external user repeats steps 1-5 until complete. 

Extensions 

4a. Invalid identification number: 

1. The system displays an error message stating that the 

identification number entered was mal-formed or 

non-existent. 

la. Network connection not available: 

1. The external user is presented with a connection error. 
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Figure 17. External user queries StatusReportWS SSD 


7 Administrator Sets the Capability Status 

Table 7. Administrator sets eapability statuses 


Primary actor 

Administrator 

Stakeholders and 

interest: 

• The administrator wants to ensure the appropriate 

status is set. 

• The external user wants to oeeasionally verify the 

status of the loeal system eapabilities. 

Entry 

conditions: 

• The loeal serviee is operational. 

• The administrator has already provided proper 

authentieation and is logged in. 

Exit conditions: 

• The administrator suceessfully sets the capability 

status. 

• The administrator receives confirmation of the status 

update. 

Main scenario: 

1. The system displays a menu option that includes the 
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option to set the status of the system capabilities. 

2. The administrator selects the option to set the status. 

3. The system displays an user interface to set the 

appropriate status. 

4. The administrator sets the status and selects to the 

option to save. 

5. The system updates the local database with the 

changes to the statuses. 

6. StatusReportWS is redeployed to the application 

server reflecting the new statuses. 

7. The system returns a message to the administrator 

confirming the status settings. 

8. The local system returns to the state at step 1 in the 

main scenario. 

• The administrator repeats steps 1-8 (if necessary) 

Extensions 

la. Connection to the database is not available: 

1. The system displays a database connection error. 

2. The system returns to the state prior to step 1. 


43 




Administrator Sets Capability Status 


Administrator 


Application 


getStatusesQ 


localDalabase 


Selects status 
for appropriate 
operation 


t 


radioButtonForm 




setVi&ibleUK) 


saveStatuses(stalus) i 


message 



setStatus(status) 


StatusReporlWS 


1 


showStatusO 


showMessageOialog(} 


Figure 18. Administrator sets statuses SSD 


8. Administrator Modifies a User Account 

Table 8. Administrator modifies a user account 


Primary actor 

Administrator 

Stakeholders and 

interest: 

• A local user needs an account to execute the system 

operations. 

• The Administrator can create, delete, or edit a user 

account. 

Entry 

conditions: 

• The local system is operational. 

• For account creation, the new user must not have an 

existing account. 

• For account deletion or editing, the user must have 

existing account. 

• The Administrator is already logged on to the system. 
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Exit conditions: 

• 

A user account is either successfully created, changed, 

or deleted. 

Main scenario: 

1. 

The system displays a main menu interface that 

includes the option to modify user accounts. 


2. 

The administrator selects the option to modify user 

accounts. 


3. 

The system re-prompts the system administrator for a 

password. 


4. 

The administrator enters the password. 


5. 

The system displays an option to either create a new 

user account or edit a user account. 


6. 

The administrator selects the option to create a new 

user account. 


7. 

The system displays an interface prompting for the 

new user’s name, account username, and account 

password. 


8. 

The administrator enters the new username and 

password. 


9. 

The administrator selects the option to save the new 

account creation. 


10. 

The system processes the request. 


11. 

The system returns a message stating that the account 

has been successfully created. 


12. 

The system returns to the state described in step 5. 


• 

The system administrator repeats steps 5-12 until 

complete. 


13. 

The system administrator returns to the main menu and 

logs off. 

Extensions 

4a. 

Incorrect Password: 


1 

. The system re-prompts for the system administrator’s 
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password. 

6a. Administrator wants to edit a user account: 

1. The administrator selects the option to edit a user 
account. 

2. The system displays a list of users that are selectable 
and the option to edit or delete the selected account. 

3. The administrator selects the user and chooses the 
option to edit. 

4. The system displays an interface with text fields 
populated with the users account information and 
capable of being manipulated. 

5. The administrator makes the changes to the user 
account and selects the option to save. (Continue 
with step #10 in the main scenario). 

6b. Administrator wants to delete a user account. 

1. Steps 1 and 2 from 6a are performed. 

2. The administrator selects the user(s) and chooses the 
option to delete. 

3. The system prompts the administrator for 
confirmation on the delete operation. 

4. The administrator confirms the operation. (Continue 
with step #10 on the main scenario). 


Figure 19 displays the SSD for the case in which the administrator modifies a 
user’s personal account. Figure 20 extends from Figure 19 displaying the administrator’s 
choice of delete and edit. Both continue after the administrator selects the option(s) as 
depicted within the red box. 
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Administrator Modifies a User Account 
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Figure 19. Modify user account (create) SSD 
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Figure 20. Modify user account (edit & delete) SSD 


C. OTHER FUNCTIONAL REQUIREMENTS 

The requirements listed in this section are those that were not specified in the use 
cases described in Subsection B. 

I. System Access 


1.1 A local user is required to have an account in order to use the system. 

48 
































1.2 The user account will include a username and password. 

1.3 Usernames will be the user’s school email address. 

1.4 Users will not be able to change their passwords. 

1.5 User passwords will be up to 15 characters in length. 

1.6 User passwords can contain any ASCII character. 

1.7 User passwords will be case sensitive. 

1.8 The ability to manage the local user accounts will be restricted to the system 
administrator. 

1.9 The system administrator will have the ability to grant or remove system 
privileges to users, change user passwords, change the system status, and to 
modify new user accounts. 

2. Database 

2.1 The Database Management System (DBMS) will use a server database type. 

2.2 The DBMS will support a relational model. 

2.3 The DBMS will utilize a Structured Query Language (SQL) engine. 

2.4 The DBMS will utilize an interface driver (e.g., JDBC, ODBC). 

2.5 The DBMS should be able to run on a Windows, Macintosh, or Linux 
operating system. 

2.6 The DBMS should have a minimum database size of 4 Gigabytes. 

2.7 The DBMS should be capable of executing, at minimum, the following Data 
Types: integers, decimal, strings, and date & time. 

2.8 The primary key will be used as the local database assertion identification. 

2.9 The DBMS will need to allow for more than one row of data per assertion. 

2.10 Any changes or service requests made to the local database must be logged 
and subsequently be capable of being queried. 
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3. Local System Functionality 


3.1 When creating and subsequently storing an assertion, the user will also have 
the option to either Store and Replace or Store and Transfer. 

3.1.1 The Store and Replace function will store the assertion in the local 
database and replace an assertion that currently exists in the external 
database. 

3.1.1.1 When a Store and Replace function is executed the local 
copy of the assertion that is replaced in the external database will 
remain in the local database with a note replacing the respective 
external ID stating a replacement has occurred. 

3.1.2 The Store and Transfer function will store the assertion in the local 
database and forward the assertion to the external database. 

3.2 When editing an assertion, the user will have the option to either 'edit' an 
existing assertion or 'delete' an existing assertion. 

3.3 When editing an assertion, the user will be shown an interface that displays 
selectable assertions with fields that show the assertions have a local ID and / or 
an external ID. 

3.3.1 When the function to 'edit' is selected and both an local ID and 
external ID exist, the selected assertion will be changed in the local 
database and the copy that exists in the external database will be replaced 
by the new version. 

3.3.2 When the function to 'edit' is selected and only a local ID exists for 
the assertion then the selected assertion will be changed in the local 
database only. 

3.3.3 When the function to 'delete' is selected and only a local ID exists 
for the selected assertion, the assertion will be removed from the local 
database. 
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3.3.4 When the function to 'delete' is selected and both an local ID and 
external ID exist, the user will be given an option to either delete the 
selected assertion from only the external database or from both databases. 


3.3.4.1 If the user selects to delete an assertion from the external 
database only, the local copy of the assertion that is removed from 
the external database will remain in the local database with a note 
replacing the respective external ID stating a deletion has occurred. 

4. Services and Clients 

4.1 The core capabilities of the system are named: KbUpdate, ExplanationGetWS, 
DataPush, and StatusReportWS. 

4.2 KbUpdate will be a client application that will allow for the transfer, 
replacement, or deletion of assertion data to the external system. 

4.2.1 The local ID generated for the assertions stored in the local database 
will be different from the external ID generated in response to a KbUpdate 
operation. 

4.2.2 An assertion can only be successfully transferred once in order to 
avoid overwriting the external ID that was originally returned. This does 
not include replacements. 

4.2.3 Feedback will be returned in the form of a message to the user either 
during or following the completion of an operation. 

4.3 ExplanationGetWS will be a local port type WS that will allow for an external 
user to request assertion data from the local database. 

4.3.1 For the external user to request assertion data from the local 
database, the external ID needs to be received. 

4.3.2 ExplanationGetWS will be deployed on the local application Server. 

4.4 DataPush will be a client application that is currently undefined. 
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4.5 StatusReportWS will be a local port type WS that will allow for an external 
user to request the status of the local system main capabilities. 

4.5.1 The status returned to the external user consists of a status message 
and a DTG for the time when the operation was last performed. 

4.5.2 A status will be assigned to each of the three key capabilities: 
DataPush, ExplanationGet, and KbUpdate. 

4.5.3 The Web service status message can be a choice between being 
'Available,' ‘Unavailable,’ or 'Unsupported.' 

4.5.4 StatusReportWS will be deployed on the local application server. 

5. User Interface (UI) 

5.1 The UI will be a Web application based on a local client / server system that 
consists of web pages a user can access with a Web browser to execute the main 
system operations. 

5.2 The use of the UI will be restricted to the local users. 

5.3 The UI will consist of a sign-in page and a main menu page with connecting 
Web pages to facilitate executing five main operations: storing assertions, 
transferring assertions, editing assertions, setting the capability statuses, and 
managing user accounts. 

5.3.1 The sign-in page will provide text fields to enter user sign-in data 
and a means to cancel the operation. 

5.3.2 The main menu will allow the user to navigate to all five main 
operations described in 3.2. 

5.3.3 The main menu will provide the user the means to log out of the 
system. 
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5.3.4 The main menu will display a list of the 10 most recently executed 
activities associated with core system capabilities along with their 
respective DTG. 

5.3.5 The main menu will allow the user to check executed activities that 
are not among the 10 most recent. 

5.3.6 The main menu will display the current capability statuses. 

5.3.7 The Transfer Assertion and Edit Assertion pages will provide a 
browsing capability for the user to look up and select assertions. 

5.3.8 The functions under the Store Assertion, Transfer Assertion, and 
Edit Assertion Web pages that either send assertion data to the external 
database, replace an existing assertion in the external database, or delete 
an existing assertion from the external database will execute the KbUpdate 
client. 

6. Application Server 

6.1 The application server must be JAVA Enterprise Edition compliant. 

6.2 The application server must provide a runtime for Web-based applications. 

6.3 The application server must allow for the deployment of Java Server Pages 
and Servlets. 

D. NONFUNCTIONAL REQUIREMENTS 

These requirements express specific nonfunctional attributes of the system’s 
environment. 

I. Usability 

1.1 The intended user is one which should be comfortable with the basic 
functionality of a Web browser, which will allow for the manipulation of an 
assertion. 
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1.2 The software must be consistent with standard Web browser-based 
applications. 

2. Reliability 

2.1 The system services must be consistently available 24 hours a day during the 
project period. 

2.2 Mean time to repair will be less than 1 hour. 

2.2 Upon a system crash and recovery the database data must be safe and 
represent what it had prior to the crash. 

3. Portability 

3.1 The software must be portable, meaning that the program must be capable of 
being executed from a Java Archive file (.jar) and / or a Web application archive 
file (.war). 

3.1.1 The portable executable files must be compatible with the Glassfish 
version 3 Application Server. 

4. Supportability 

4.1 The software must be capable of accommodating updates to the XSD, WSDL, 
or general changes. 

4.2 The program code must be well commented to allow for future analysis and 
modification. 

4.3 The program code must be well commented modular code to support testing 
procedures. 
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E. SUMMARY 


In this chapter, we provided an SRS for our proposed distributed system. The SRS 
utilized use cases to demonstrate the funetional requirements and those speeifie 
requirements not mentioned in the use eases were explained in sub-section C. The 
sequence diagrams were created to demonstrate the interaction of the processes which 
would be needed to execute the core operations and also the order in which they would 
perform. We used these requirements to help us design the proposed system that is 
covered in Chapter IV. 
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IV. SYSTEM DESIGN 


This chapter presents a design of the proposed distributed system based on the 
requirements defined in Chapter III. We have broken down the system into four main 
tiers to be developed as depicted in Figure 21. The four tiers represents the fundamental 
architecture that our client application and service will use for deployment. 



Database 

Tier 



Remote 

Client 


Figure 21. Four tiers of development 


A. DATABASE TIER 

Based on the stakeholder’s requirement of a relational database mentioned in 
Chapter III, our first step was to build a conceptual data model (CDM) of the underlying 
database schema. A CDM is high-level visual representation that uses concepts such as 
entities, attributes, and relationships to describe a database application (Elmasri & 
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Navathe, 2007). Specifically, we will use an entity-relationship (ER) diagram, which is a 
popular type of CDM, to represent our database. To avoid redundancy while ensuring 
scalability, we normali z ed our database by using an algorithm that performs several steps 
to map an ER diagram into a Relational Database Schema (RDS) (Elmasri & Navathe, 
2007). Eigure 22 shows our ER diagram. To clarify what our ER diagram depicts, we will 
briefly discuss what the aforementioned concepts found in CDMs mean. 

• Entities represent a thing (conceptual or physical) in the real world that 
exists independently. In our diagram entities are depicted as the green 
rectangular boxes. Entities that have an additional outline around the 
rectangle are called weak entities, which means that they do not have a key 
attribute and are related to a specific entity called the owner entity 
(Elmasri & Navathe, 2007). 

• Attributes are specific properties of an entity. Attributes that are 
underlined are considered to be key attributes, which means that they are 
unique in value. Attributes are depicted as yellow circles. Multi-valued 
attributes are depicted with a double circle and represent data that can be 
greater than one set. Composite attributes are those that have additional 
sub-attributes (e.g., the sub-attributes for a person’s address are: street 
number, street name, zip code, city, and state). Composite attributes are 
displayed with extra lines attached to their sub-attributes. 

• Relationships can exist between entities and serve to describe an 
association between them. Relationships are depicted as orange diamonds 
and those having an additional outline around the diamond relate weak 
entities to its owner entity (Elmasri & Navathe, 2007). The number 1 or 
letters N and M adjacent to the relationship represent a cardinality ratio 
that depicts the maximum number of instances that an entity can 
participate in (e.g., 1:N means a one-to-many relationship). 
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1 . 


ER Diagram 


In our ER diagram, we listed LocalUserAccounts as a regular entity with the user 
email attribute as the key attribute. LocalUserAccounts is an owner entity that shares a 
1:N relationship 'Sets_the' with the weak entity called Capability Status. Since only one 
user (system administrator) can set the capability status this type of association between 
entities is called partial participation and is displayed as a single line connecting the 
relationship to the entities. LocalUserAccounts shares a 1:N relationship 'Manages' with 
itself, which represents the system administrator’s ability to manage user accounts. 
LocalUserAccounts also shares a M:N (many-to-many) relationship 'Creates_an' with a 
regular entity Assertion, whose key attribute is Local_ID. The double lines extending 
from LocalUserAccounts to Assertion represents an association between entities called 
total participation, which means that all local users can create an assertion (Elmasri & 
Navathe, 2007). Assertion is an owner entity type that shares a 1:1 relationship with 
DataSource, KbEvidence, KbSupport, and a KbClaim. These weak entities are the 
major elements of an assertion that have been determined by the SCIE stakeholders thus 
far. DataSource is a new element that is currently under evaluation so we decided to 
include this element into our design. 
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Figure 22. Database ER diagram 


2. Relational Database Schema 

Taking the ER diagram developed in our first step we used the following steps to 
map the ER diagram into a Relational Database Schema (RDS). The schema in turn 
guides the design of the database tables. 

a. Mapping of Regular Entity Types 

Eigure 23 displays the RDS, which initially includes LocalUserAccount 
and Assertion. They are both assigned their own relation with email and locallD, 
respectively, as their primary keys. 
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Figure 23. Mapping of regular entity types 


b. Mapping of Weak Entity Types 

In step 2, relations that are created for the weak entities, which include 
only the non-multivalued attributes are added to the RDS. 


LocalUser Account 

Assertion 

CapabilityStatiis 
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DataSource 


firstNanie 

lastName 

email 

password 


locallD 

ext_ID 
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Figure 24. Mapping of weak entity types 


c. Mapping of Binary 1:1 Relationship Types 

In step 3, we merged all of the weak entity relations created in step 2 with 
their owner entity (Assertion) keeping locallD as the primary key. 
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d. Mapping of Binary 1:N Relationship Types 

In step 4, we added foreign keys in both CapabilityStatus and 
LocalUserAccount; both of which refer to LocalUserAccount’s primary key: email. 

LocalUser Account 



CapabilitvStatus email kbiiStatus dpStatus egStatus kbuDTG dpDTG egDTG 

Figure 26. Mapping of binary 1:N relationship types 


e. Mapping of Binary M:N Relationship Types 

In step 5, we create a new relation called 'Creates_an' that houses two 
foreign keys referring to the primary keys in LocalUserAccount and Assertion. 
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Figure 27. Mapping of binary M:N relationship types 


/. Mapping of Multivalued Attributes 

Finally, in step 6, we map the multivalued attributes to their own relations 
containing their respective attributes along with a foreign key that refers to the primary 
key of Assertion. Figure 30 depicts the proposed database tables that will be created for 
the system. The table names are the relation names on the side of the attributes and the 
column names are the attributes themselves. We populated the database with sample data 
and we will discuss that process in Chapter V. 
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Figure 28. Mapping of multivalued attributes 


B. BUSINESS LOGIC TIER 

I. XML Schema 

In Chapter II, we discussed XML schemas and their significance. In this section 
we present aspects of the XML schema related to our client and services. The schema 
was generated by Richard Tong, a representative from lARPA-Scientific, Engineering 
and Technical Assistance branch. As of May 4, 2010 the current version of the schema is 
1.2. We modified and renamed the schema in order to accurately reflect the structure of 
the assertions agreed on by the UMD stakeholders. We also employed two versions of the 
schema, one for our Web services and one for our client. By doing so, we were able to 
remove the XML syntax that did not pertain to the respective operations, which made the 
lines of XML easier to manage and sped up the program compilation process. The 
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StatusReportWS and ExplanationGetWS services utilize UMDSchema_12b.xsd. The 
KbUpdate client uses STEPSchema_12b.xsd. In the Appendix, we have listed one 
schema that includes the data types and elements defined in both versions. 


a. StatusReportWS 

The schema element StatusReportResponseMsgPart, shown in Eigure 29, 
represents the service response to the incoming request. It is constructed with two sub¬ 
elements: Metadata and Payload. 

<xs:element name="StatusRepoftResponseMsgPart"> 

1 <xs:annotation> 

I <xs complexType> 
i I <xs:sequence> 

I I <xs:element name- Metadata^ 

I I <xs;complexType> 

I I <xs;sequence> 

I I <xs:element name='’Messageld''type="xs:string"> 

I I i I <xs:annotation> 

i [ I </xs:element> 

I I I <xs;element name="Requestorid" type="xs:string"> 

i I I j <xs:annotation> 

i I I </xs:element> 

I 1 </xs:sequence> 

i I </xs:complexType> 

I I </xs:element> 

I I <xs:element name="Payload"> 

i j <xs:complexType> 

i I I <xs-sequence> 

i I <xs;element name=''StatusRetumBundle"lype='’stepd:StatusRetumBundle7> 

I 1 i </xs:sequence> 

1 j </xs:complexType> 

i I </xs;element> 

i I </xs.sequence> 
i </xs:complexType> 

</xs :element> 


Eigure 29. XME schema StatusReportResponseMsgPart 


Metadata is composed of the message and requestor identification that is 
submitted in the request and is subsequently returned. The Payload element holds a 
sequence of sub-elements and types, including StatusRetumBundle, that eventually 
provide the capability status. 

Eigure 30 shows the ServiceStatusReport type that holds the individual 
client and service capability status. Although not depicted for brevity, each sub-element 
capability is composed of a State and a EastDtg. The State is of type ServiceState that is 


65 










the simple type deseribed on the top. LastDtg is of type dateTime, whieh is an integer¬ 
valued year, month, day and time strueture (W3C, 2004). 


<xs simpleType name="ServiceSfate”> 

<xs annotation> 

<xs restriction base=''xs string”> 
j i <xs enumeration value="availaWe7> 

<xs enumeration value="unavailable’'/> 

\ <xs:enumeration value="unsupported“/> 
i </xs:restriction> 

<yxs:simpleType> 

<xs comptexType name=‘'ServiceStatusReport"> 

I <xs annotation> 

<xs sequence> 

<xs element name='’KbUpdateCapab«lity”> 

<xs annotation> 

<xs complexType> 

1 j I <xs sequence> 

j i j ^ <xs element name="State" type="stepd SefviceSt3te7> 

i i i <xs element name="L3st[)tg“ type='xs dateTime”/> 
j I </xs:sequence> 
i </xs complexType> 

\ <yxs.element> 

<xs element name=’'DataPushCapafcHlity' > 

I <xs element name="ExplanationGetCapab(lity"> 

I </xs sequence> 

<yxs:complexType> 

Figure 30. XML sehema ServieeState and ServieeStatusReport 


b. ExplanationGetWS 

Figure 31 shows the ExplanationGetResponseMsgPart, whieh is the root 
element that comprises the message to be returned to the client. In similar fashion to 
StatusReport, it contains a Metadata and Payload. The Payload houses an 
ExplanationRetumBundle that, although not depicted, also has a set of Metadata and 
Payload. This sub-Metadata holds the Assertionid that references the particular data to be 
obtained from our database. The sub-Payload subsequently contains the main elements 
that make up an assertion that are listed under the complex type KbAssertion in Eigure 
32. Although, in concept, the key elements to an assertion remain as the claim, evidence, 

and support, the KbAssertion is made up of two elements, the AssertionMetadata and 
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AssertionContext. However, AssertionClaim, AssertionSupport, and AssertionEvidence 
are of separate individual types that are further defined in Figures 34, 35, and 36. 

<xs element nanie="ExplanationGetRGSponseMsgPart"> 

I <xs annota!ion> 

I <xs complexType> 

I I <xs:sequence> 

I ! <xs element nam€='Melad3ta’> 

I I I <xs complexTypG> 

I I ' I I <xs sequence> 

I M I I I <xs element name="Mess3geld' type-xs stnng"> 

I I I I I I ‘ <xs annotation> 

j I I j i <Jxs elemenl> 

! I i i ! 1 element name='Request<wld" t^'pe='xs stnng'> 

11:111: <xs annot3tion> 

t I : : I ! 

I I M I I <Jxs elemenl> 

I I j I I </xs sequence> 

I I ; • </xs complexType> 
i I ^ <ixs element> 
i i . <xs element name=’Payload’'> 

I I ; j <xs complexType> 

I I I i «xssequence> 

i I ■ I I i <xs element name='ExplanationRetumBundle" type="stepd ExplanationReturnBundle7> 

I M i I <Jxs sequence? 
i I ' I </xs:comp(exType> 

I I : o’xs element? 
i I <yxs sequence? 

I </xs complexType? 

</xs element? 

Figure 31. XMF schema ExplanationGetResponseMsgPart 


AssertionMetadata is composed of three elements including 
AssertionFlag, which is also defined in the schema. The AssertionFlag is designed as an 
enumeration of the value: 'Public' and 'Private,' which represent viewing authorization 
labels for the assertion. AssertionContext has an element called DataSet that is of type 
DataSource. Figure 33 shows DataSource. The elements and types defined within 
KbClaim, KbEvidence, and KbSupport were specified by the UMD teams. 
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<xs complexType name-'KbAssertion“> 

<xs sequence> 

I <x8:el8tnem name='Ass«ttionMetadata"> 
i i <xs £omplexType> 
i : <xs sequence* 

i j : I <xs element name^' AssertionlcI " type-"x8:string > 

j i : I <xs elenwnl name="AssertionDlg' type-'xs daleTime'* 

j j ; : <xs element name- AsserlionFlag ' type- stepd AssertionFlag'* 

i i ; </xs sequence* 
i j </xs comptexType* 
i <Jxs element* 

j <xs element name=‘'AssertionContext'* 
i I <xs:complexType> 

I j : <xs.sequence* 

i j : j <xs element name-LanguageUseDomajn'type^'xs stnng* default-Persuasion Attempt' * 

j I M <X8 element n8me=' DataSet" type=' stepd DataSource'* 
i j i </xs sequence* 
i j </xs comptexType* 
i <fxs element* 

I <X8:element name='A8seftionClaim“ type='stepd KbClaim"/* 

I cxs.element name='AssenionE'(idsnce'type=’stepd Kb&idence'/> 
i <xs element rame="AssertionSupport‘ type='stepd KbSupport "/* 

<txs sequence* 

</xs comptexType* 

Figure 32. XML schema KbAssertion 


<xs comptexType rtame="DataSource"> 

<xs annotation* 

<xs sequence* 

<xs element name='’DataMetadata"* 

I i <xs annotation* 
i <xs complexType* 
i i <xs sequence* 

I I i j <xs element name="SourceName" type="xs:string"> 

<xs element name="SourceLocation" type="xs anyURl"* 
j I i I <xs element name="SoufceLanguage" typ©="xs language"* 

I j i i <xs element name="SourceType" type="xs:stnng"> 

! i : j <xs element name="SoutceMedium' type="xs string"* 

I </xs sequence* 
i j </xs:comptexType> 

I </xs element* 

I <xs element name="DataSegmenf minC>ccurs="0" maxOccurs="unbounded"* 
I j <xs annotation* 

! <xs complexType* 

I i i <xs sequence* 

I i : j <xs element n8me="SourceDataSegment" type="xs stnng"/* 

i j </xs sequence* 

I </x8;comptexType* 

I </xs element* 

</x8 sequence* 

</xs: c 0 m plexType * 

Figure 33. XML schema DataSource 
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<xs complexType name="KbClaim"> 

<xs sequence> 

<xs element name=' PtedicateClaim"> 
i <xs complexType> 

! I j j <xs sequence> 

i i j i ; <xs element name-'PredicaleName" type='xs slnng" default='Persuasion AttempC/> 

I I j i i <xs element name- 'Speaker'> 

I i j j i j <xs comp(exType> 

I ! j i I I - <XE.sequerKe> 

j i j i i ! j <xs element iiameri'Enlily'lype='’slepd Enlity'/> 

I i I i i I </xe sequer>ce> 

i i j I i I <yxs.complexType> 

j j j j i </xs.elemenl> 

I i j I : <xs.el9ment name^'Tafget"? 

I i j j I I <xs comp)9xType> 

I i i j i I ; <xs:sequonc9> 

I ! I 1 i i ; j <X8. element name-'Entity" type-'stepd Entity' maxOccurs="unboundod7> 

I I : j i i ; </xs:sequer>ce> 

I I j j i ; ; <xs:at1ribute name='type" type="X8 stnng' def8ult='dlrected"> 

! ! ! 1 i 1 <j'xs complexType> 

Ml!; <7x8 element> 

I ! : i <yxs sequence> 
i </xs complexType> 
j I <yxs eiement> 
i </xs sequence> 

</xs complexType> 


Figure 34. XML schema KbClaim 


<xs complexType name="KbEvidence"> 

; <xs sequence> 

i ; <xs:element naiTie=’EvidenceValue"type="xs;string'> 
i : <xs element name^' EvidenceStatement" lype='stepd E\adenceStalement7> 
i <yxs sequence > 

</x8 complex!ype > 

<xs complexType name='EvidenceStatemenf> 

I <xs:sequence> 

<xs element name='ConstituentMultiset"> 

! <x8:complexType> 

i I j <xs sequence> 

I i I i <xs element name='PetsuasionTactic'' maxOccuis="unbounded”> 

i I i I i <xs:complexType> 

j I j ; i I <xs group ief=*stepd PeisuasionTacticGioup7> 

I • i ! i </x8:complexType> 

j I i j </xs element> 

I I I </x8.sequence> 

i <yxs complexType> 

j j </xs element> 
i </xs sequence> 

<Jxs complexType> 

<x8:group name='PersuasionTacticGroup‘> 
i <xs all> 

<x8;element name='tactic'type='xs:string"/> 
i <xs element n8me='startline" type="xs integer"/> 

1 <xs.element name='endline" type- xs.integef"/5 
• I <xs element name='doc'type='xs stnng"/> 

I </xs all> 

</xs group> 


Figure 35. XML schema KbEvidence 
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<xs compJexType name=''KbSupporf> 

I <xs sequence> 

I i <xs element name=TheoreticalFrame“ type="xs string'7> 

I I <xs element name=TechnicalTerm" maxOccurs="unbounded"> 

I j j <xs complexType> 

I i I I <xs sequenco 

I j j I I <xs element name='TechnicarTermGloss" type="xs string"/> 

I I i 1 I <xs element name=’'DataSnippet” type="xs.string7> 

I I I I </xs sequence> 

j i i I <xs altnbute name="term’ type="xs:string" default="redefinition7> 
I I I </xs complexType> 
i i </xs element> 

I </xs.sequence> 

<7x5 comp)exTyp€> 

Figure 36. XML schema KbSupport 


c. KbUpdate Client 

KbUpdate is a client and the KbUpdateRequestMsgPart, pictured below, is 
the root element comprising our request message to the external system. The request is 
sent to the external system to update the external knowledge base with assertion data. The 
request can either add a new assertion, delete a existing assertion, or replace an existing 
assertion from the external database. As depicted, the request contains Metadata and 
Payload. The Metadata contains a message identification and the requesting team 
identification. The Payload is composed of an option of element bundles representing the 
desired type of update. Figure 38 displays the AssertionAddBundle. The 
AssertionAddBundle element has Metadata that addresses the number of assertions to be 
updated and is called AssertionCount. The Payload contains the element Assertion and 
references the same elements and types previously defined in the ExplanationGet 
description. 
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<xs:element name='KbUpdateRequestMsgPa(t''> 

: <xs annoiation> 

; <xs complexType> 

: I <xs sequence> 

I <xs element name="Metadata'> 
i I : I <xs:comptexType> 

i I I I ; <xs sequence> 

i ! i I : i <xs element name="Messageld'' type="xs stfing"> 

; i I I : I element name- TeamJd" type="stepd Teamld"> 

I ! i I I </xs sequence> 

I j I i </xs:complexType> 

: I ! </xs element> 

<xs element name="Payload'> 
i i i ! <xs comp(exType> 

MM; <xs chotce> 

<xs element name="AssertionAddBundle'’ lype=”stepd AssertionAddBundle"/> 

M M ii <xs element name="AssertionReplaceBundle'' type='stepd AssertionReplaceBundle’'/> 
; j I j M <xs:element name="AssertionDeleteBundle" type="stepd;AssertionDeleteBundle"/> 

M I i i <Acs choice> 

mm </xs complexType> 
i i i </xs element> 

I </xs sequenco 
; <7x5 complexType> 

</x8 element> 


Figure 37. XML schema KbUpdateRequestMsgPart 


<xs:complexType name="AsseftionAddBundle"> 

<xs annotation> 

<xs sequence> 

I I <xs element name='Metad3ta"> 
i I ! <xs complexType> 

I I I I <xs sequence> 

I i I I I <xs element name="AssertionCounf> 

1 I I I I . 

I I I I I I <xs 3nnotation> 

I I I I I I <xs simp)eType> 

I 1 I I I I I <xs restriction base=''xs:integer’’> 

I i M I i M <xs:minlnclusrve value='17> 

I I I I > I t * 

I I I I j I I </xs festriction> 

I j i I I I </xs simpleType> 

I I i I I </xs element> 

I I I i </xs sequence> 

I ! I </xs.comp(exType> 
i I </xs element> 
j I <xs element name='P3ytoad"> 

I I j <xs complexType> 

I I I <xs:sequence> 

III I <xs element name-'Assertion" type=’stepd.KbAssertion’' maxOccurs-unbounded’> 
j I I </xs sequence> 

I I I </xs comp»exType> 

I I </xs element> 

I </xs sequence> 

</xs.comptexType> 

Figure 38. XML schema AssertionAddBundle 
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The AssertionDeleteBundle (Figure 39) also contains Metadata and 
Payload elements. The Metadata is similar to the AssertionAddBundle, however now the 
AssertionCount refers to the number of assertions to be deleted. The Payload on the other 
hand refers to the particular identification number of the assertion(s) to be deleted. The 
AssertionReplaceBundle (Figure 40) uses the same Metadata and Payload structure 
where the AssertionCount refers to the number of pairs of assertions to be swapped. The 
Payload’s sub-elements describe both the identification number of the assertion from the 
external database to be replaced and the particular assertion from the local database that 
will replace it. Again, this Assertion is of type KbAssertion described in the 
ExplanationGet. 

<xs complexType name='AssertionDeleteBundle’> 

I <xs annotation> 
i <xs sequence> 

I I <xs element name="Metadata"> 

I I j <xs complexType> 

I I I I <xs sequence> 

11:11 <xs element name='AssertionCount"> 

i i i i ’ 

I j I I </xs.sequence> 

j I I </xs complexType> 

I j </xs element> 

I 1 <xs element name="Payload"> 
i I <xs complexType> 
i i I I <xs sequence> 

I I I I i <xs element name="Asser1ionld" type='xs string" maxOccurs="unbounded"> 

I j j I </xs sequence> 

I I 1 </xs:complexType> 
i j </xs element> 

I </xs sequence> 

</xs complexType> 

Figure 39. XML schema AssertionDeleteBundle 
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<xs complexType name="AssertionReplace8undle”> 

<xs annotation> 

<xs sequence> 

I <xs element name='Metadata"> 

I I <xs complexType> 
i j I <xs:sequenc8> 

I I i ! <xs element name="AssertionCount"> 

I j </xs.sequence> 

I I </xs.complexType> 
i </xs.element> 

I <xs element name='Pay1oad*> 

I I <xs compJexType> 

I I I <xs sequence> 

i I I i <xs element name-’AssertionPair" maxOccurs="unbounded"> 

I I j i j <xs annot3tion> 

I I j I ; <xs complexType> 

I j I I i I <xs sequence> 

I I I I i ! I <xs element name="ReplacedAssertionld" type='’xs string''> 

I I i i i I j <xs element name="Assertion* type="stepd KhAssertion’> 

I I I I j j </xs sequence> 

j I i i I </xs.complexType> 

I I I I </xs.element> 

I I I </xs sequence> 

I I </xs complexType> 

I </xs element> 

</xs sequence> 

</xs complexType> 

Figure 40. XML schema AssertionReplaceBundle 


2. Class Diagrams 

Earlier, we showed the readers our proposed domain model that provided a 
conceptual perspective of the system as a whole. In this section, we used the same UML 
modeling notation to provide class diagrams that provide the software-focused structural 
view of the system, with the main elements indicated by boxes. Each box contains three 
sections: name (top section), attributes (middle section), and functions (bottom section). 
In the following sections, we will walk through the class diagrams for our StatusReport 
service, ExplanationGet service, and KbUpdate Client. 
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a. StatusReport 


Figures 41 and 42 display the class diagram for the StatusReport service. 
Class StatusReport implements the client interface SR_PortType and is dependent on the 
request message received that is of the type StatusReportRequestMsgPart. The message 
will contain both a message ID and a requester ID (Metadata), which are eventually 
returned to the client as part of the StatusReportRequestMsgPart along with the Payload. 
This Payload class refers to a StatusRetumBundle class, which also has a sub-class called 
Payload that refers to the class ServiceStatusReport. ServiceStatusReport has the three 
subclasses, which hold the methods that work closest to the Database class in order to get 
the information from the database. KbUpdateCapability, ExplanationGetCapabiltiy, and 
DataPushCapability refer to the ServiceState class, which holds an enumeration of string 
literals: Available, Unavailable, or Unsupported. Finally the Database class implements 
the Connection interface, which provides the methods for interacting with our database. 
The Connection class is a Java 2 platform object 
(http://download.oracle.eom/docs/cd/E17476_01/javase/l.3/docs/api/java/sql/Connection.html). 
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Figure 41. StatusReport class diagram part I 
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Figure 42. StatusReport class diagram part II 
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b. ExplanationGet 



Figure 43. ExplanationGet class diagram part I 

Figures 43 through 46 display ExplanationGet. ExplanationGet 
implements the ExplanationGetPortType and is dependent on the request message of type 
ExplanatioGetRequestMsg. Similar to StatusReport the same Metadata that comes in the 
message is returned to the client along with the Payload. The Payload refers to an 
ExplanationRetumBundle class that contains a Payload and Metadata. The Payload is 
actually a list of assertions, which are instances of the Kb Assertion class. Kb Assertion 
has two components called AssertionMetadata and AssertionContext. AssertionMetadata 
calls the DataBase class directly while AssertionContext refers to DataSource. 
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Kb Assertion also refers to KbClaim, KbSupport, and KbEvidenee shown on Figure 45. 
Each of these classes either contain instances of classes that call the DataBase class or 
call the DataBase class directly in order to obtain the assertion referenced by the assertion 
ID used in Payload. 
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Figure 44. ExplanationGet class diagram part II 
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Figure 45. ExplanationGet class diagram part III 
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Figure 46. ExplanationGet class diagram part IV 
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c. KbUpdate 



Figure 47. KbUpdate class diagram part I 


Figure 47 above shows the first half of the KbUpdate client class diagram. 
Our request message contains Metadata and Payload. The Payload holds a bundle 
depending on the operation desired. Each of the bundle classes have their own 
components that continue in Figure 48. The AssertionAddBundle and 
AssertionReplaceBundle eventually use the same class path structure to obtain the 
assertion data as the ExplanationGet service. AssertionDeleteBundle only has one class 
that handles the list of assertion IDs to be removed from the external database. 
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Figure 48. KbUpdate class diagram part II 


C. WEB TIER 

In this section we will describe the design of the WSDL documents for our client 
and services. We employed two WSDL files; one for KbUpdate called 
STEPPortTypes_12b.wsdl and another for both ExplanationGet and StatusReport called 
UMDServices_12b.wsdl. We did this because our prototype, discussed in Chapter V, 
consists of two separate applications; one for the Web services and the other for the Web 
client. The WSDE files were modified and renamed from the documents originally 
generated as stepGovServices_12.wsdl and stepPortTypes_12.wsdl (Tong, 2009). The 


82 


























































binding and service sections of the UMD Services WSDL were left for us to define since 
they pertained to our network protocol details. Sub-sections 1 and 2 show the main 
sections of the WSDL files. 

1. UMD Services 


<wsdl:types> 
i <xs :schema> 

I <xs:import namespace="http://www.iarpa.gov/SCIL/STEP_Schema" schemaLocation="UMDSchema_12b.xsd7> 
</xs:schema> 

</wsdl:types> 

<wsdl;message name='’ExplanationGetRequest"> 

<wsdtpart name="omnia" element-'stepd:ExplanationGetRequestMsgPart7> 

</wsdl :message> 

<wsdl:message name-'ExplanationGetResponse''> 

<wsdl;part name-'ornnia" element="stepd:ExplanationGetResponseMsgPart7> 

</wsdl:message> 

<wsdl: message name="StatusReportRequest''> 

<wsdl part name-'ornnia” element=''stepd;StatusReportRequestMsgPart"/> 

</wsdl:message> 

<wsdl message name="StatusReportResponse''> 

<wsdl:part name-'ornnia” element=''stepd:StatusReportResponseMsgPart”/> 

</wsdl:message> 


Figure 49. UMD services WSDL part I 


Figure 49 above shows the types and messages sections. The Schema document 
was generated separately and is referred to in the types section by name. The messages 
section shows the part name 'omnia' to represent the name of the request and response 
messages to be used between service and client. Figure 50 shows StatusReportPortType 
and ExplanationGetPortType as the portTypes to be used by the client. The message 
types previously defined are referenced here as the input and output messages. 
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<wsdl portType name="StatusReportPortTyp€''> 

<wsdl:documentation>Core service. Hosted at the Performer site </wsdl:documentation> 

<wsdl;operation name="StatusReport"> 

i <virsdl:documentation>Request-Response STEP AppServer requests a status report from Performer team service </wsdl:documentation> 
! <wsdl:input message=”steps:StatusReportRequest7> 

! <wsdl:output message="steps:StatusReportResponse7> 

</wsdl:operation> 

</wsdl:portType> 

<wsdl.portType name=''ExplanationGetPortType''> 

<wsdl:documentation>Optional service. Hosted at the Performer site. </wsdl:documentation> 

<wsdl:operation name="ExplanationGet"> 

I <wsdl:documentation>Request-Response STEP AppServer requests an explanation from Performer team setvice.</wsdl:documentation> 
! <wsdl:input message="steps:ExplanationGetRequest'7> 

! <wsdl:output message="steps:ExplanationGetResponse7> 

</wsdl:operation> 

</wsdl:portType> 


Figure 50. UMD services WSDL part II 


<wsdl:binding name="StatusReportSoap0inding" type=''steps;StatusReportPortType"> 

I <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http7> 
<wsdl operation name="StatusReport"> 

<soap12;operation soapAction="statusReport" soapActionRequired="true'7> 
j <wsdl;input> 

<soap12:body use="literar7> 

</wsdl:input> 
j <wsdl;output> 

<soap12:body use="literar7> 

</wsdl:output> 
i </wsdl.operation> 

</wsdTbinding> 

<wsdl:binding name="ExplanationGetSoapBinding'‘ type="steps;ExplanationGetPortType"> 
i <soap12:binding style-'document" transport="http://schemas.xmlsoap.org/soap/http7> 
<wsdl:operation name="ExplanationGef'> 

<soap12;operation soapAction="explanationGet" soapActionRequired="true’7> 
i <wsdl:input> 

j j <soap12:body use='’literar7> 

</wsdl:input> 

] <wsdl;output> 

I <soap12:body use="literar7> 

</wsdl output> 

I </wsdl.operation> 

</wsdl:binding> 

Figure 51. UMD services WSDL part III 
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Figure 51 shows the binding between the serviee interfaee deseriptions 
(StatusReportPortType and ExplanationGetPortType) to the their respeetive serviee 
implementations (StatusReport and ExplanationGet). Note that we are using SOAP over 
HTTP. 


Einally, Eigure 52 shows the service section combining the previously defined 
port names and binding names to our network address creating the end-point. 

<wsdl service name="UMD_Service"> 

<wsdl port name="StatusReport" binding="stepn;StatusReportSoapBinding”> 
<soap12;address location="http://10.3.2E97:8080/UMD/UMD_Service7> 

</wsdl:port> 

<wsdl port name="ExplanationGet" binding="stepn;ExplanationGetSoapBinding"> 
i <soap12:address location="http;//10.3.21.97:8080/UMD/UMD_Sefvice7> 

</wsdl:port> 

</wsdl:service> 


Eigure 52. UMD services WSDE part IV 


2. UMD Client 

Eigure 53 shows the KbUpdate WSDE. Aside from the name changes in the 
messages, ports, and binding sections that reflect the KbUpdate operation, the structure of 
this document is the same as the UMD Services WSDE. The service section provides the 
combination of the binding and port names and also specifies the network address of the 
external service. 
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Figure 53. UMD client WSDL 


D. PRESENTATION TIER 

We now shift our focus to the presentation tier, which contains the components 
that create and execute the UI necessary for our users to communicate with the other tiers 
in the system. 

Based on the requirements from Chapter III, a closed Web application is 
necessary to implement the UI. Using a closed Web application to serve as our UI means 
that only our users will be presented with the Web pages to interface with and execute the 
system functionality; similar to how a person would use the Internet to manage his/her 
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personal online banking account. The UMD performer team users will perform the 
system operations by using the Web pages to interface with the local system’s business 
logic through an HTTP connection. The interaction is initiated with a request for a Web 
page by the user’s Web browser. The local system’s Web server will return the requested 
Web pages to the users for execution. The File system manages the HTML files for the 
Web server and the Application server executes the server-side business logic (Conallen, 
2003). Figure 54 shows the interplay among the components. 



Application 

Server 




Web Browser 


44D00 

File System 


External 

Systems 


Figure 54. Web architecture (From Booch, 2001) 


The remainder of this section is separated into two sections. In Section 1, we used 
the Microsoft PowerPoint 2007® application to develop a conceptual design of the UI 
Web pages. We also discuss the intended functionality behind each Web page and step 
through what a user would encounter while using the Web application. Section 2 shows 
the respective Web pages’ UML class diagrams. 

1. UI Web Pages 

We begin our design of the UI with another UML modeling tool called an 
Activity Diagram. This diagram displays the workflow associated with our UI. As 
depicted in Figure 55, the basic structure of the UI allows a user to sign in and view the 
main menu. The main menu provides the user an option to perform one of several system 
operations. Finally, the user can sign out of the system when complete. 
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a. Sign In 

The first step for our users would be to sign into our system through a sign 
in page that requires the user to input a username and password. Figure 56 displays our 
proposed design of what that page would look like. 
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Figure 56. Sign-in Web page 


b. Main Menu 

Figure 57 represents a preliminary design of the main menu, which is 
displayed following user authentication. The main menu will display the status of the 
core system capabilities, show the ten most recent activities, provide the user a means to 
exit the system, and provide the user hyperlinks to navigate to the desired Web pages to 
perform the system functions. For clarity purposes, we designed the main menu image to 
show only four activities instead of ten. A DTG is associated with the activity. The newer 
and older buttons under the recent activity will allow the user to view additional activity 
not displayed. A color-labeled display on the top right corner shows the current state of 
the core capabilities. The buttons in yellow serve as hyperlinks to the Web pages. 
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Figure 57. Main menu Web page 
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c. Store Assertion 

If the user wishes to store an assertion that has not been previously stored 
into the local database, the user would select the Store assertion tab. The application 
would then provide the user a Web interface to input the assertion data. For 
demonstration purposes, we provide two pages shown in Figures 58 and 59. However, the 
data could be input by using just one Web page. When complete, the user is given one of 
three store options to execute: 

• Store —Stores the assertion in the local database only. 

• Store and Transfer —Stores the assertion in the local database and then 
executes the KbUpdate client to add that assertion to the external database. 

• Store and Replace —Stores the assertion in the local database and then 
executes the KbUpdate client to transfer that new assertion over to the 
external database in order to replace an existing assertion. 
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Continue Cancel 


Figure 58. Store assertion I 
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Figure 59. Store assertion II 
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When the user seleets the option to Store and Replaee, the applieation 
would display the Web interfaee depleted in Figure 60. The interfaee allows the user to 
seareh for the assertion by using one of two seareh options: by external ID or author. The 
output of the seareh would be displayed in a form that allows the user to seleet only one 
assertion that is eurrently in the external database. Upon seleetion, a short summary is 
displayed for the user to view before replacement. 


R4^|«1 a4*«* 


Search for the assertroii that wrll be replaced by 


External ID 


Search 


Author 


Search 


Select llie a.^seiluni that will be leplacecl 


F.xIrrnallD 

I.ocaim 

Author 

DTG 

Air.'C? 

3 

Til omas Jones 

2010 -01 -0.5T17:00:00 -O' :00 


IP 

TlioinasJcmes 

2010-01-10118:00:00 05:00 

U78R45 

15 

lliomag Jones 

2010-01-15'115>:00:00-05:00 


10 


will lejilace 


A"8Bdl 


Replace Back Cancel 


Figure 60. Store assertion III 


d. Transfer Assertion 

The Transfer assertion operation will execute the KbUpdate client for 
assertions that have been previously stored in the local database only. Figure 61 shows, 
upon selection, that the application will provide the user an option between sending an 
assertion not currently in the external database or to transfer an assertion meant to replace 
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an existing one. Figure 62 shows the interfaee upon seleetion of the Send a new assertion 
option. The user is provided a means to seareh for and to seleet the assertion(s) to be 
transferred. If the user seleets the option to Replace an existing assertion the user will 
first ehoose the assertion that will do the replaeing using a Web page similar to Figure 62. 
The user will then seleet the assertion to be replaeed through a Web page that looks 
similar to Figure 60. 


Choose one: 

% Replace an existing assertion 
9 Send a new assertion 


Continue Cancel 


Figure 61. Transfer assertion I 
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Ti’iiiiMlVr 


Scaich t'oi the asseitioiHi? i rliar •will be sent by 

Search 


Local ID 


Author 


Search 


Select the as.s*eitK>n(3) diat will be forwaided: 


■ 

Local ID Author 

DTG 

■ 

4 Robert Uecker 

2010-01-10T18:00^>0-05;00 


Transfer 


Back 


Main 

Mcmi 


Figure 62. Transfer assertion II 


e. Edit Assertion Data 

The Web interface under the Edit assertion operation will allow the user to 
select an assertion based on a search for either the author or the assertion local ID. The 
user would then have the option to either edit or delete the selected assertion. 

After a user selects an assertion and chooses the option to edit, an interface 
capable of being edited, similar to Figures 58 and 59 above, will appear with the text 
fields populated with the current assertion data. The user could change the data in the text 
fields and save the new data. If an external ID was associated with the assertion selected 
for editing, then the KbUpdate client will execute and replace the assertion in the external 
database with the newly modified version; otherwise the newly edited assertion will be 
stored locally with the same local ID. Figure 63 displays the Edit Assertion Web 
interface. 
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If the user seleets the delete option, and there is not an external ID 
assoeiated with the assertion, then the assertion will only be removed from the loeal 
database. However, if there is an external ID assoeiated with the assertion to be deleted, 
the user will reeeive a prompt, as depleted in Figure 64, to deeide between deleting an 
assertion from the external database only, or deleting the assertion from both the loeal 
and external databases. In either ease, the external ID for that assertion will no longer be 
reeognized by the external system, and will be removed from the loeal database. The user 
ean also seleet the help button to understand the ramifications of his/her decision. In 
either case, the KbUpdate client will be executed to delete the respective assertion 
referred to by the external ID. 


E<lit A.s.^^rtioii 


Scaichfoi the a>!scitioiito be edited bv 


Local ID 


Search 


Aiithoi 


Search 


Select llie .•i.'serluui to be edited: 


■ 

F.xlmi al ID 

Local ID 

Author 

DTG 

9 

Al2.'r>7 

3 

Ttiomaslnncs 

2010-01-05T17:00:00-0.’:00 

9 

A123BTR 

16 

Robert Ueckef 

2010-01-1 011 8:00:00-OiiOO 

9 

U65QGX 

12 

Gladys Knight 

2010-01-l.ni5>:00;00-05:00 

9 

csbiqx 

8 

Frccicriilc Feucicr 

2010 - 01-0 m 0 : 00 ; 00 -05 :00 


Edit Delete 


Main 

Menu 


Figure 63. Edit assertion 


95 

















Choose one: 

% Delete from external database only 
% Delete from both databases 

Delete Biirk Help 

Figure 64. Edit assertion II 


e. Set Capability Status 

The Set Capability Status operation will only allow an administrator to set 
the capability status. If a non-privileged user would attempt to access this operation, the 
application would generate a message for the user stating that the user does not have 
those privileges. The Web interface will show the administrator three sets of radio 
buttons per capability. The administrator would select the appropriate status per 
respective capability, and then save the operation (see Figure 65). 
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Select tlie rapaltilit^* wtatiiN 

O Available 

KbUpDATE # IJitavailahle 
# Uiunipporled 


• A\ ailabk- 

DATAPUSH 0UIu,^mlal>lc 

# Unswpported 


# A\iulable 

EXPLANATIONGET ^ Uiiaviulable 

• I njaipported 

Save Cancel 


Figure 65. Select the status 


f. User Accounts 

The User Accounts operation is also restricted to administrators in the 
same way as setting the capability statuses. When selected, the administrator will be 
given the option (Figure 66), to either create account or to modify account. 

If the administrator selects the option to create account, the application 
will display an interface with text fields for entering the user’s personal data. When 
complete, the administrator would save the user account information, thereby storing the 
data in the local database. See Figure 67. 

If the administrator selects the option to modify account, a Web interface 
listing all of the users will be shown. The administrator would select the user account to 
perform either a modify or delete function (Figure 68). If modify is selected, the 
administrator will be presented with an interface capable of being edited (Figure 69), but 
with the text fields populated with the user’s account data. The administrator can make 
changes as necessary and save the changes, thereby updating the local database. If the 
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administrator selects delete, the application will prompt the administrator for 
confirmation. After confirmation, the user account data will be permanently removed 
from the local database. 


Choose one: 

% Create aecount 
% IslodifH' ace omit 

Continue Cancel 


Figure 66. User account I 


Arrouiit 



(■:< tile Usei ID I 


Oeyle Cancel 


Figure 67. User account II 
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Figure 68. Modify account 
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Figure 69. Update account 


2. UI Class Diagrams. 

We now present the models of the UI Web application using UML class 
diagrams. It is important to note that the original UML standard notations were never 

intended to represent Web pages. It was not until the Web Application Extension (WAE) 
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for UML was adopted that Web pages were capable of being represented by new 
modeling notations. Jim Conallen, co-founder of UML, states that the extension to UML 
is expressed using the following mechanisms: stereotypes, tagged values, and constraints 
(Conallen, Modeling Web Application Architectures with UML, 1999). In his book. 
Building Web Applications With UML Second Edition, Conallen describes these 
mechanisms as follows: 

Stereotype, an extension to the vocabulary of the language, allows us to 
attach a new semantic meaning to a model element. Stereotypes can be 
applied to nearly every model element and are usually represented as a 
string between a pair of guillemets: « ». However, they can also be 
rendered by a new icon. 

Tagged value, an extension to the property of a model element, is the 
definition of a new property that can be associated with a model element. 

Most model elements have properties associated with them. Classes, for 
instance, have names, visibility, persistence, and other attributes 
associated with them. A tagged value is rendered on a diagram as a string 
enclosed by brackets. 

Constraint, an extension to the semantics of the language, specifies the 
conditions under which the model can be considered well formed. A 
constraint is a rule that defines how the model can be put together. 
Constraints are rendered as strings between a pair of braces: {}. 

Conallen defines three core class stereotypes: Server page. Client page, and 
HTML form; all three of which comprise the aforementioned mechanisms. These classes, 
and the stereotype class associations described in Table 9, were used to design the class 
diagrams in the following pages. Figure 70 shows the WAE class diagram for the main 
menu. 
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Table 9. Stereotyped assoeiations (From Conallen, 2003) 



Figure 70. Main menu 
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From the main menu, the user could choose among the five operations. Figure 71 
shows the interaction between the classes for the case when the user chooses to store an 
assertion. This model demonstrates that a user can still replace a current assertion in the 
external database after its initial creation at the local level. As per the requirements in 
Chapter III, the diagrams depict feedback in the form of a Web page after the successful 
completion of the respective operation. 



Figure 71. Store assertion 


Figure 72 shows the user’s choice in transferring an assertion that has only been 
stored locally. Again, the user does have the option to replace an assertion currently in 
the external database; that option is a continued in Figure 73. 
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Figure 72. Transfer assertion 



Figure 73. Transfer assertion II 
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Figure 74 shows the user’s option to either edit or delete an assertion from the 
databases. The form DeleteForm provides the user another option, to remove the 
assertion loeally only or from the external database, too. 



Figure 74. Edit assertion 


Setting the capability status requires the administrator to choose from one of three 
sets of radio buttons per capability. The selected button is represented in the form 
DeleteForm. See Figure 75. 
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Figure 75. Set capability statuses 


Finally, the administrator is given the option either to create a new user or modify 
an existing user account. See Figure 76. 



Figure 76. User accounts 
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D. SUMMARY 


In this chapter, we took the requirements from Chapter III and used them to 
provide the readers our proposed system design. We began our design with the Database 
tier, wherein we summed up and displayed the attributes, entities, and relationships of the 
system in an ER diagram. We followed up by using an algorithm to map the ER diagram 
into an RDS, which we will use to create our database tables. Our next step was to design 
the Business Eogic tier by presenting aspects of our XME Schema and generating the 
UME class diagrams that express the functionality of the core operations of our system: 
the StatusReport WS, the KbUpdate client, and the ExplanationGet WS. Eor our Web 
tier, we presented the WSDE documents that we will use as our endpoints. Einally, for 
the Presentation tier, we showed the reader our design for the Web pages to be used by 
the local user to operate the system, followed by the Web application UME class 
diagrams. In Chapter V, we present our prototype of the system to be used by the UMD 
performer team. 
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V. PROTOTYPE 


In Chapter I, we described the basic system features that the UMD performer 
team would need in order to contribute to the SCIL program. The first focused on the 
local user’s management of the assertion data that would allow for the collection, storage, 
and modification of the assertion prior to distribution. The second was to allow for 
remote access to the data. This ability is realized with the use of our core Web services 
described in Chapter III (StatusReportWS and ExplanationGetWS). The third feature was 
the ability to transfer the data to the external knowledge repository over the Internet. Our 
Web service client, KbUpdate, has been designed to manage the transfer of assertion data 
to the external database; this includes the ability to replace and delete assertion data. 

In this chapter, we will describe the prototype of the system. Our prototype 
consists of a database store that supports our two core Web services (StatusReportWS 
and ExplanationGetWS), and our Web service client (KbUpdate). The prototype also 
involves the application server in which the Web services are deployed. Our objective for 
this prototype was two-fold. Eirst, we wanted to provide a proof of concept 
implementation for both Web services and WS client in support of the preliminary 
engineering tests. Second, we wanted to provide the stakeholders with a working system 
capable of being modified and upgraded for their future use. 

Our system was developed in an Apple® Macintosh desktop computer running 
OS X. This chapter begins with the implementation of our local database. We will 
describe the database tables we developed to interact with the business logic of our 
system. Next, we present our Web services followed by our client. Using screenshots of 
the applications, we will walk the reader through the sequence of events that transpire in 
order to execute each operation. 

A. MYSQL DATABASE 

Although the SRS in Chapter III described the DBMS to be a Relational-type, we 
also researched into the feasibility of using an Object-Oriented Database Management 
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System instead. In the end, we seleeted the MySQL Community Server version 5.1.49 
DBMS (www.mysql.oom) for our prototype beoause the database is, at this point in time, 
required to handle only simple data types (i.e., numbers and strings). This edition of the 
MySQL DBMS is also open-soureed, and is oompatible with the NetBeans Integrated 
Development Environment (IDE), whioh we used to develop our applioations. Based on 
the RDS we designed in Chapter IV, we oonstruoted a total of six tables to support our 
system operations: status, assertionData, claimTarget, contextDataSegment, 
evidenceStatements, and supportTechTerm. 

1. Status 

Eigure 77 displays a desoription of the status table that we generated using SQE. 
The Eield oolumn on the left holds the names of the eolumns in the table. The status table 
is queried for all six values whenever the StatusReportWS is eonsumed by the external 
elient. The DTG eolumns are separately updated with the sueeessful exeeution of either 
the KbUpdate or DataPush elients or when the ExplanationGetWS has been eonsumed. 


tiysql> describe status; 


Field 

-4.- 

1 Type 

.4.- 

1 Null 

1 

-4.- 

Key 1 Default 

1 

- + 

Extra 1 








kbu_status 

1 varcharC25) 

1 NO 

1 

1 NULL 

1 

1 

dp_status 

1 varcharCZS) 

1 NO 

1 

1 NULL 

1 

1 

eg_status 

1 varchar(25) 

1 NO 

1 

1 NULL 

1 

1 

kbu_dtg 

1 datetime 

1 YES 

1 

1 NULL 

1 

1 

dp_dtg 

1 datetime 

1 YES 

1 

1 NULL 

1 

1 

eg_dtg 

1 datetime 

.4.- 

1 YES 

.4.- 

1 

1 NULL 

-4.- 

1 

1 

- + 


& rows in set (0.00 sec) 


Eigure 77. MySQE status table 


2. AssertionData 

Eigure 78 represents the assertionData table. This table holds all of the assertions 
that are referenced by both locallD and externallD. However, not all of the assertion data 
can be found in this table. We needed to generate four other tables to hold the remainder 
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of the data because those tables would be required to hold at least one row of data per 
assertion. To handle this one-to-many relationship, we created a foreign key called 
'locallD' in claimTarget, evidenceStatements, supportTechTerm and contextDataSegment 
that referenced locallD from assertionData. This relationship allowed for the entire 
assertion data to be inserted into and read from our database tables. Figure 79 shows the 
four additional tables. 


Field 

1 Type 

1 Null 

1 Key 1 

Default 1 Extra 






locallD 

1 int(ll) 

1 NO 

1 PRI 1 

NULl 1 auto_increment 

dtg 

1 timestamp 

1 NO 

1 1 

CURRENT_TIMESTAMP 1 

flag 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

externallD 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

display 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

strength 

1 float 

1 YES 

1 1 

NULL 1 

version 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

theoretical_franie 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

predicate_name 

1 varchar(50) 

1 YES 

1 1 

NULL 1 

speaker_type 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

speaker_id 

1 int(ll) 

1 YES 

1 1 

NULL 1 

tgtAttributeType 

1 varchar(25) 

1 YES 

1 1 

NULL 1 

lang_use_dom 

1 varchar(50) 

1 YES 

1 1 

NULL 1 

sourceNatne 

1 varchar(45) 

1 YES 

1 1 

NULL 1 

sourcelocation 

1 varchar(45) 

1 YES 

1 1 

NULL 1 

sourcelanguage 

1 varchar(45) 

1 YES 

1 1 

NULL 1 

sourceType 

1 varchar(45) 

1 YES 

1 1 

NULL 1 

sourceMedium 

1 varchar(45) 

+ - 

1 YES 

• +- 

1 1 

- +-+ 

NULL 1 

- + - 


Figure 78. MySQL assertionData table 
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mysql> describe claimTarget; 

+ - + - + - + - + - + - + 

I Field I Type I Null I Key I Default I Extra I 

+-+-+-+ - +-+-+ 

I externallD I varcharCZS) I YES I I NUll I I 

I locallD I varchar(50) I YES I MUl I NUll I I 

I tgt_type I varchar(50) I YES I I NUll I I 

I tgt_entity_id I int(ll) I YES I I NUll I I 

+ - + - + - + - + - + - ^ 

4 rows in set (0.00 sec) 

mysql> describe evidenceStatements; 


1 Field 

1 Type 

1 Null 

1 Key 1 Default 

1 

Extra 1 







1 externallD 

1 varchar(25) 

1 YES 

1 1 NUll 

1 

1 

1 locallD 

1 varchar(50) 

1 YES 

1 MUl 1 NUll 

1 

1 

1 doc 

1 varchar(500) 

1 YES 

1 1 NUll 

1 

1 

1 start_line 

1 int(ll) 

1 YES 

1 1 NUll 

1 

1 

1 end_line 

1 int(ll) 

1 YES 

1 1 NUll 

1 

1 

1 tactic 

+- 

1 varchar(50) 

.j.- 

1 YES 

- +- 

1 1 NUll 

- + - 

1 

- + ' 

1 

-+ 


6 rows in set (0.00 sec) 


mysql> describe supportTechTerm; 


1 Field 

1 Type 

1 Null 

1 Key 1 Default 

1 

Extra 1 







1 externallD 

1 varchar(25) 

1 YES 

1 1 NUll 

1 

1 

1 locallD 

1 varchar(50) 

1 YES 

1 MUL 1 NULL 

1 

1 

1 gloss 

1 varchar(2500) 

1 YES 

1 1 NULL 

1 

1 

1 term 

1 varchar(S0) 

1 YES 

1 1 NULL 

1 

1 

1 data_snippet 

+- 

1 varchar(2500) 

■ +- 

1 YES 

-+- 

1 1 NULL 

- +-+- 

1 

-+- 

1 

-+ 


5 rows in set (0.01 sec) 


mysql> describe contextDataSegment; 

+-+-+-+-+-+-+ 

I Field I Type I Null I Key I Default I Extra I 

+-+-+-+-+-+-+ 

I externallD I varchar(25) I YES I I NUll I I 

I locallD I varchar(50) I YES I MUl I NUll I I 

I d_segment I varchar(2000) I YES I I NUll I I 

+ - + - + - + - + - + - + 

3 rows in set (0.00 sec) 

Figure 79. MySQL assertion-related tables 


B. UMD OPERATIONS 

Now that the reader has seen our underlying data store, let us turn to the execution 
of the three core prototype operations. We designed our applications with the NetBeans 
IDE version 6.8, an open-source application development tool, using the Java^’^ 
Development Kit 6 update 20. Both Web services were developed under one Java Web 
application project, entitled UMD, and subsequently deployed to the open-source 
Glassfish Web application server version 3. The program required to manage the 
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assertion data and the capability status was developed using the Java Standard Edition 
application called NPS_SCIL. A rudimentary command line UI supported by Java Swing 
GUI components were developed to assist the local user in running the program—the 
ideal UI being the Web application designed in Chapter IV. 

1. StatusReport 

a. Setting the Status 

A local user can execute the NPS_SCIL application by running the 
NPS_SCIL.jar file created from the compiling process. As displayed in Figure 80, upon 
execution, the user is presented with a set of options. Selecting the 'update' command will 
generate a window for the user to select the appropriate status per capability. When 
finished, the user clicks on the 'Okay' button that executes an excerpt of the Java code 
displayed in Figure 81, which calls the method named writeCapabilityStatus(), displayed 
in Figure 82, to insert the desired status values into the database table status shown in 
Figure 83. 


To on assertion external Koowledge lose, type tt»e nord: •nodi^y’. 

To quU type: . 

quit 

c+iurch:- cnortcllS jffwo jor "/Uwrs/onorteU/Ooxknloods/l'^.SCII 
To Rtor^ 0 new A«i*rtion, type the word: 'stone*. 

To Jpdotc the stot'js of our core copc^iUtics, type the mord; 'update'. 

To nodify on assertion fro* rxtrrnol KfKmIrdgc ftose, type the Mord: 'nodify'. 
To quit type: 'quit*. 



church:- crartellS jowo -jor **/Users/CTTorteU/DowTtloods/>PS.SQL/dist/HPS.SCIL.)ar* 
To sto-^ a n&tt Assertion, tyae the word: 'store*. 

To update the stotjs of our core capobiUtkeb, type the uord: 'update'. 

To iTOdify on assertion fron external Knowledqe Base, type the uordi 'trodify*. 

To quit type: 'quit'. 


update 


User enters ‘iipdale’ which generates the I I. 


NbUpOct* 




© 

O' 


Olm y ( Ciwi.l ^ 


Figure 80. Executing NPS_SCIF.jar 
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ir CiRaiicS. isSelected ()) ( 
dpS'acus = - .-a, - - 

} else if (:RadioB«tron5.i3Selecced())< 
dpSia'us = ("On-n’ai:. ); 

I else < 

dpSfatus - C ' 

} 

if (TRadisBjtfon'’.isSelec'ced()) < 
egSracus = ''Rvaiiatlc '); 

} else if (jP.adioButtor.S .isSelectedI)) { 
egSiafus • (""..a ;..^^1= ); 

) else < 

egS'acus = !" r ?."); 

} fry < 

DaiataseConnection ccr. " r.ew DatabaseCorj.ecf icn (); 
cor..wriceCapabilitySfafU3 (icbuStatus, dpStatus, egScatus); 

uOpfionPane.s/iot'teiSdgeUialoglnull, " ...= ._ Jtati ■ ;.ai .jct , '.r 

Sysfea.sxittO); 

Figure 81. Method call to write the statuses 


public void writeCapabilityStatns (Bering Icb, Bering dp, Bering eg) ebrows Excepeion { 

String sglStmcl • "'^onsTE: ; - - .3 '' .concat(lcb)+'" , ' - 

■- : a:.u; ' .cor.cat (dp)+•' • , ^ .concac (eg); 

cry { 

Class. i orNaie (dr iverHaste) ; 

con = DriverManager.geCConnecrion('JRI., USESUfAKE, PASSWORD); 
seat. = ccn.prepareSeaeeroent (sqlSensel) ; 
s'rt:.execueeUpdaee{); 

> catch (SOLExceptlon e) { 
e.printStackTrace(); 

) finally (ccn.close();) 

) 

Figure 82. Connection to the database 


mysqb select kbu.stotus, dp.status, eg_stQtus, kbu.dtg, dp.dtg, eg_dtg from status; 

+.+.+.+.+.+.+ 

I kbu.status I dp.status I eg_status I kbu.dtg I dp.dtg I eg.dtg I 

+.+.+.+.+.+.+ 

I Available I Unavailable I Available I 2010-07-31 13:27:35 I 2010-07-31 11:37:44 I 2010-07-31 11:38:07 I 

+.+.+.+-+.+.+ 

Figure 83. Status table after execution 


112 







b. The Web Service 

The Web application can be executed by running the UMD.war file 
generated from the compiling process. Prior to deploying the WS to the Glassfish server, 
we tested it by using the open-source software called soapUI version 3.0.1 
(www.eviware.com). This software allows users to act as clients and consume Web 
services over the Internet. This was important to us because we needed a way to 
determine if the correct data was returned upon a query from the external client. Figure 
84 shows the soapUI split screen interaction between the client’s request on the left and 
the StatusReportWS response on the right. 


! Request 1 


O □ O • [hnp;/yk>calhost;48394/UMD/UMD_Serv)ce 


<soap:EnveIope xmhs;soap ="http://www.w3.org/2003/05/soap-envelo 
<soap:Header/> 

<soap:Body> 

< step: StatusRep oitRe que stMsgPart> 

<step:Metadata> 

<step:MessageId> checkStatus </step;MessageId> 

< step :Re que st orId> GOV /st ep :Re que storId> 
</step:Metadata> 

</step:StatusReportRequestMsgPart> 

</soap:Body> 

</soap:Envelope> 


I^SEnvelope xmlnsf ="http://www.w3.ors('2003/05/soap-envelope" > 

<S:Body> 

<StatusReportResponseMsgPart xmlns ="http://www.iarpa.gov/SCIL/STEP_Schema" 
<Metadata> 

<MessageId> checkStatus </MessageId> 

<RequestorId> GOV </RequestorId> 

</Metadata> 

<Payload> 

<StatusRetumBundle> 

<Payload> 

< StatusRep ort> 

<KbUp dateC ap abiHty> 

< State > available </State> 

<LastDtg> 2010-07-31T13;27:35-08:00</LastDtg> 
</KbUpdateCapability> 

<D ataPushC ap ability> 

<State>unavailable </State> 

<LastDtg> 2010-07-31Tll:37:44-08:00</LastDtg> 

</D ataPushCap ability> 

<EKplanationGetCapabiHty> 

< State > available </State> 

<LastDtg> 2010-07-31Tll:38:07-08:00</LastDtg> 
</E^lanationGetCapability> 

</StatusReport> 

</Payload> 

</StatusRetumBundIe > 

</Payload> 

</StatusRep ortResp ons eMs^ art> 

</S:Body> 

</SEnveIope> 


Figure 84. Testing StatusReportWS 


Following the successful test, we deployed the UMD.war file to the 
Glassfish server to be consumed by the external client, as depicted in Figure 85. 
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Figure 85. Deploying UMD 


2. KbUpdate client 

In this section, we step through the execution of the KbUpdate client. The 
functionality behind the options to either add, delete, or replace was discussed in detail in 
the two previous chapters. In this section, we will focus on the ‘adding’ function of the 
client. An assertion needs to be in the local database before the update so we will begin 
with storing the assertion. 

a. Storing the assertion 

Figure 86 below shows the execution of the NPS_SCIL.jar file from the 
command line. The user selects the option to 'store.' The user is presented with an 
interactive window to enter the assertion data. When the user is finished, he clicks on the 
'save' button, which runs the code that executes five separate SQL statements in order to 
store the assertion data into its respective tables, described in section A.2 above. The 
system generates a local ID for the assertion and inserts that ID into all five assertion- 
related tables in the same row(s) that pertains to that assertion. Figure 87 shows an 
excerpt of the assertionData table that highlights the local ID and the lack of an external 
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ID at this point in the sequence. Note in Figure 87 that the predicate_name and 
lang_use_dom columns share the same data; this is because the data entered was for test 
purposes. 
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Figure 86. Storing an assertion 


aysql> select locallD, dtg, extemolID, pre<l»cate_natne, speoker.id, speoker.type, lana_use_do«i from ossertionOoto; 


locallD 1 dtg 1 cxternolID 

1 predicote.none 1 

speokcr.ld 

spcakcr_type 

long.usc-dom 

2 1 

2010-07-30 13:32:17 1 NULL 

1 Persuasion Attenpt 1 

1 

test 

Persuasion Attempt 

3 1 

2010-07-30 14:12:10 1 lM>5e0S3t)«o 

1 Persoosion Attempt 1 

1701 

person 

Persuasion Attempt 

6 1 

2010-07-31 12:21:53 1 NULL 

1 Persuasion Attempt 1 

1 

test 

Persuasion Attempt 

7 1 

2010-07-31 12:35:58 1 NULL 

1 Persoosion Attempt 1 

1 

test 

Persuasion Attempt 

S 1 

2010-08-03 09:20:59 LJtJLL 

1 Persuosion Atteept 1 

123 

person 

Persuasion Attempt 

9 1 

2010-08-03 09:43:5aCi NUlQ 

1 Persuosion Attempt 1 

123 

person 

Persuasion Attempt 


Figure 87. Assertion in the database 
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b. Updating the External Database 


From the command line, instead of selecting 'store,' the KbUpdate client is 
run by selecting the option to ‘modify.’ The application then gives the user the option to 
either add, delete, or replace. The user selects the option to 'add' and is then prompted for 
a message ID and for the locallD of the assertion to be added. When the user submits the 
locallD to be transferred, the system reads the respective assertion data in all five 
assertion-related tables and sends the data to the external system. Figure 88 is a 
screenshot of the Web page generated by the external system’s Web server called the 
STEP server, which displays the list of assertions currently in the external database 
(Naval Research Laboratory, 2010). For this demonstration, the listing created on 2010- 
08-03 refers to the assertion with local ID #9. Figure 89 is a screenshot of another STEP 
server generated Web page that shows the specific ID #9 assertion elements following the 
successful transfer (Naval Research Laboratory, 2010). The external system generates 
and returns an external ID that refers to that assertion, and the local system writes that 
external ID into the rows of the five tables that pertain to the local copy of the assertion 
that was just sent. Eigure 90 shows two of the five tables with external ID 
'UMDb39f43Ia.' 
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>-* J V y \ ■■ y \ ; ..-w...... ....^■www-r^^ . w. , W ♦D- * 


Most Visited'' Getting Started Latest Headlines ^ How to install 0B2 E... 



Simple Query Query Summary 

team: UMD. langUse: 

Results (Found 5 current assertions) 


Language 

Use 

Team 

Created 

Language 

Source 

Type 

Visibility 

Persuasion 

Attempt 

UMD 

2010-08-03 

English 

NRL34 

Blog 

Public 

Persuasion 

Attempt 

UMD 

2010-07-30 

English 

NPS/UMD 

Blog 

Public 

Persuasion 

Attempt 

UMD 

2010-05-25 

Spanish 

SourceName 

blog 

a 

Private 

Persuasion 

Attempt 

UMD 

2010-05-25 

English 

SourceName 

email 

Private 

Persuasion 

Attempt 

UMD 

2010-05-25 

Spanish 

SourceName 

blog 

a 

Private 


Figure 88. External Web server 
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Assertion UMDb39f431a 



Figure 89. External Web server 


seXtci locolXD. dig, extenwlID, pretficdK.rore. sp«»k«/*.ici, 

..........---—---—4......—.-..4. 

I locolIO I dtg • ext«rnalID I predtcote^nare I speoker.td I 
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S9«oker.t>pe I lor^us«.don I 


2 I 2019-07-33 13:32:17 

3 I 2019 07 30 14:12:19 
$ I 2019 07-31 12;21;!»3 

7 I 2019-07-31 12:35:58 

8 I 2019-08-03 09.20:59 

9 I 2019-08-03 09:43: 


I Ptnuasion Attempt 1 1 I test 

.M)S9983hSd I Persuasion Attempt I 1701 I person 

MA.L I Persuosion Attempt I i I test 
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J Persuasion Attempt I 123 I person 

>Cb39f431o_J Persuasion Attempt I 123 I person 
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I Pervjosion Attempt 
I Persuosion Attempt 
I Persuasion Attempt 
I Persuasion Attempt 
I Persuasion Attempt 
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1 extemollO 
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1 rJJU 

1 2 


11 
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15 1 Redifinitior 
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1 l»CW8iljbga 

1 3 

1 

24 1 

24 1 tivothy 
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1 NULL 

1 4 


1 1 

1 1 test 
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1 MULL 

1 5 


I 1 

2 1 test 

1 

1 NULL 

1 6 


1 1 

2 I test 

1 

1 NULL 

1 7 


t 1 

2 1 test 

1 
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3 1 Eivethy 
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9 HMS in set (9.00 s«c) 


Figure 90. External ID in the database 
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ExplanationGetW S 


b. The Web Service 

Now that we have data that is ready to be retrieved, we test the WS using 
the soapUI software, as shown in Figure 91. The key component to the request is the 
external ID. Using the external ID, the local system retrieves the respective assertion data 
located in the assertion-related tables. Finally, with the successful test of the 
ExplanationGetWS using soapUI, we deployed the .war file to the Glassfish server for its 
subsequent consumption by the external client, as shown in Figure 85. 


<soap;Envelope xmlns;soap =''http://viTOw.w3.org('2003/05/soap-en^ 
<soap:Header/> 

<soap;Body> 

<step :E}q>lanationGetRe que stMsgP ait> 

<step:Metadata> 

<step;MessageId> Get9 </step:MessageId> 
<step:RequestorId> GOV </step:RequestorId> 
</step:Metadata> 

<step:PayIoad> 

<stepE}q:)lanationRequestBundle> 

<step:Metadata> 

<step:AssertionId> IJMDb39f431a[^/step:AssertionId> 
</step:Metadata> 

</stepExplanationRequestBundle> 

</step:Payload> 

</step:ExplanationGetRequestMsgPart> 

</soapEody> 

</soapEnvelope> 


..- ' 


E 




<AssertionEvidence> 

<EvidenceValue> Future Evidence value </EvidenceValue> 
<EvidenceStatement> 

< C onstituentMuItis e t> 

<PersuasionTactic> 

<tactic>Empathy </tactic> 

<startline> 2</start]me> 

<endllne> 3</endJine> 

<doc>blogspot.com_stormpetrel_20050326205100_ARB_20050 
</P ersuasionX actic > 

</ C onstituentMuItis et> 

</EvidenceStatement> 

</As s ertionEvidenc e> 

< Ass ertionSupp ort> 

<TheoreticaIFranie> This interaction includes use of a redefinition tactic a 
persuasive force of the redefinition tactic comes in its ability tomarshal pre-existing 
beliefs about tiie categories its linked to. This isessentially a way to refi'ame a situation, 
often in subtle ways. Empatliy grows out of Cialdini's particular category Liking, which 
states thatwe tend to be convinced by those we like or admire. </TheoreticalFrame> 
<TechnicalTerm term="redefinition" > 

<TechnicalTermGloss> Redefinition is an agent's attempt to reframe th' 
that something bears a certain property (Predications)or b) analogizing it to 
something else (Analogy). </TechnicalTermGloss> 

<DataSnippet> "I have heard with great sorrow that some of our brethr 
killed while expressing their opposition to the aggression of the forces of the 
crusader America and its allies against the Muslims' territories in Pakistan and 
Af^anistan." </DataSnippet> 

</Te chnic alT erm> 

</As s ertionSupp ort> 

</Assertion> 

</Payload> : 



Figure 91. Testing ExplanationGetWS 


C. USER FEEDBACK 

With the operating prototype in hand, we obtained an acceptance test by a UMD 

representative. We had the representative step through the following sequence of 
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operations: setting the capability status, storing a new assertion, transferring an assertion, 
replacing an assertion, and deleting an assertion. The StatusReport WS and all three 
functions of the KbUpdate were fielded in order to assist in the completion of a series of 
engineering tests with the external system. Knowing that not all of the desired features 
were implemented in the prototype, the representative was satisfied with the prototype 
because it accomplished its intended purpose, and it allowed for future modifications as 
necessary. 

At this point, the system has been used in multiple engineering tests following 
directed changes to the XSD by both lARPA and UMD. An agreed-upon structure of an 
assertion is still under discussion by the UMD stakeholders, so actual assertions have yet 
to be generated and forwarded to the external database. 

D. SUMMARY 

In this chapter, we used the system design discussed in Chapter IV to develop our 
proposed prototype automated system to manage the assertion data generated by the 
UMD performer team. The prototype provides a means for the stakeholders to validate 
the system design and a working platform for follow-on research and development. 

We used the MySQL server as our database and created six tables to store the data 
necessary to execute the core operations. Our Web client application provides multiple 
functions including: 

• the ability to add, replace, or delete assertions 

• the ability to store an assertion into the database 

• the ability to set the capability statuses 

We also provided screenshots of the assertion as displayed in the external STEP 
application server. Both of our Web services and our Web client were developed using 
the Java programming language. We demonstrated to the reader the WS testing results 
using the soapUI software. Finally, we deployed our Web services to the Glassfish 
application server in order to await future external client requests. 
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VI. CONCLUSION 


A. SYNOPSIS 

The goal for this thesis was to design and develop an automated system to be used 
by the UMD performer team in support of the SCIL program led by lARPA. The SCIL 
program seeks to investigate various methodologies to help understand the social goals of 
people by demonstrating a relationship between these goals and their particular language 
use. UMD’s role in the program is to identify the social goals that pertain to persuasion 
by analyzing chat-based Web forums. The end product of the analysis of the unstructured 
text is a set of assertions that declare acts of persuasion were attempted. 

The system we designed enables users to locally store, manage, and transfer the 
assertions to the external system. Eventually, SCIL will be combined with a functionality 
that uses artificial intelligence techniques to process raw text. The processing will result 
in assertions that are then forwarded to an external knowledge base run by lARPA. 

In Chapter I, we stated that the solution to the system required by the UMD 
performer team in the short run stemmed from the answers to the following questions: 

1. What are the requirements for system to be implemented by the NPS 
performer team ? 

2. What is the appropriate design of a modular framework to effectively 
manage the natural language assertions in a knowledge base repository 
and the sharing of the knowledge via the World Wide Web? 

3. What is the appropriate Web-service design to allow for multiple users to 
update the knowledge base repository of natural language assertions from 
multiple sites ? 

To address these questions, we began our research with an investigation of SOA 
and Web services. This background information introduces the key concepts we 
expanded upon in the remainder of the thesis. 
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Chapter III began with the introduction of an abstract system domain model that 
showed the components and their relationships to one another. We then presented the 
stakeholder-validated software requirements to answer question number one. The SRS 
included several use cases and SSDs to demonstrate the core system functionality. This is 
the initial version of the requirements specification, and is subject to iterative 
development based on the needs of the stakeholders. 

For questions two and three, we started with an illustration of the four main tiers 
of the system architecture: database, business logic, Web, and the presentation. We then 
delved into each tier and discussed its respective design features. For the database, we 
presented an ER diagram and then followed a six-step algorithm to normali z e the 
elements into a relational database design. The business logic tier was addressed by 
showing the particular system data types and elements of the XML schema to be used in 
the creation of our WS and client, along with their respective class diagrams. For the 
Web tier, we presented elements of our WSDL, which described our WS interfaces for 
our future clients. Lastly, using PowerPoint, we prototyped the layout of the graphical 
user Web interface that will enable the local users to perform the core system 
functionality including managing the assertion data and capability status. We finished the 
design of our presentation tier with the Web application class diagrams. 

The thesis concludes with a description of the SCIL prototype that we 
implemented. We demonstrated the execution of the system functions by walking the 
reader through a scenario that involved a user setting the capability status and also 
performing the three main functions of the KbUpdate client. 

The significance of this research is that it will support the analysis of the social 
dynamics behind certain groups of interest by managing the assertions generated from 
online chat communication. The prototype will serve as a vehicle to elicit additional 
requirements for SCIL. 

B. FUTURE WORK 

The prototype described in this thesis uses a relational database schema to 

organize the system data. We did not delve into the use of an object-relational or an 
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object-oriented database management system. Since we used an object-oriented 
programming language to develop the system software, it would seem to be more 
efficient to use a database that is designed to store objects instead of tuples. The data 
types used in the prototype where simple and easy to implement using MySQL, but a 
RDBMS does not handle complex data types as well as object-relational or object- 
oriented database management systems. An analysis of using either of these database 
management systems is a subject of future research. 

The system design did not address concurrency issues that can be encountered 
when, for example, two or more users attempt to concurrently modify the same assertion. 
A race condition is a particular example of a concurrency issue. Stallings defines a race 
condition as “A situation in which multiple threads or processes read and write a shared 
data item and the final result depends on the relative timing of their execution” (Stallings, 
2009, p. 207). An analysis of these system issues and their consequences would help to 
ensure that the integrity of the data is not compromised. 

We designed a Web GUI for the system, but this feature was not implemented in 
our prototype. An analysis of some of the popular Web-development technologies (e.g., 
Ajax Frameworks, Java Server Faces, and Microsoft’s ASP.Net) is needed to identify 
which of these techniques should be used to implement the deployed system. 

The intent behind the DataPush client mentioned in Chapter III is still in debate 
amongst the UMD stakeholders. Since the KbUpdate client already sends assertions to 
the external system, it would be redundant to implement another Web client alongside 
KbUpdate to perform the same function. We recommend that the DataPush client either 
be dropped from further discussion or clearly specified to warrant the development of 
another Web client. 
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APPENDIX. XML SCHEMA 


<?xml version="1.0" encoding="UTF-8"?> 

<!-- edited with XMLSpy v2010 (http://www.altova.com) by Davien Palomo (Naval 
Postgraduate School) --> 

<xs:schema xmlns:stepd="http://www.iarpa.gov/SCIL/STEP_Schema" 
xmlns:xs="http: //WWW. w3.org/2001/XMLSchema" 
targetNamespace="http: //WWW. iarpa.gov/SCIL/STEP_Schema" 

elementFormDefault="qualified" attributeFormDefault="unqualified" version="l.3d 
xml:lang="EN"> 

<!-- Schema Documentation --> 

<xs:annotation> 

<xs:documentation> 

XSD for STEP (the lARPA SCIL Program SOA Platform) 

Original Publication Date: 2009-10-26 
Current Date: 2010-08-27 
Current Version: 1.3d 
</xs:documentation> 

<xs:documentation> 

Change Log (from Version 1.2) 

2010-07-14 : Makes claims predicate-based; no wildcards 
2010-07-16 : Enumerates claims by team 

2010-07-21 : Changes the claim context element to SocialConstructDomain--an 
enumerated type 

2010-08-21 : Adds a SocialConstruct element to the assertions context--a simple 
string 

</xs:documentation> 

</xs:annotation> 

<!-- Global Types used in defining KB content --> 

<!-- Utility Types--> 

<xs:complexType name="DataSource"> 

<xs:annotation> 

<xs:documentation>Type that defines the data source used in generating an 
assertion. 

</xs:documentation> 

</xs:annotation> 

<xs:sequence> 

<xs:element name="DataMetadata"> 

<xs:annotation> 

<xs:documentation>Metadata that describes the source of the data. 

</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="SourceName" type="xs:string"> 

<xs:annotation> 

<xs:documentation>The name of the source.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="SourceLocation" type="xs:anyURI"> 

<xs:annotation> 

<xs:documentation>A URI that allows the data to be located. Can be a dummy 
value.</xs:documentation> 
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</xs:annotation> 

</xs:element> 

<xs:element name="SourceLanguage" type="xs:language"> 

<xs:annotation> 

<xs:documentation>The human language of the source.</xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs:element name="SourceType" type="xs:string"> 

<xs:annotation> 

<xs:documentation>The type of source: blogj emails broadcast conversation^ 
etc.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="SourceMedium"> 

<xs:annotation> 

<xs:documentation>A enumerated list. Currently just text or 
speech.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:enumeration value="text"/> 

<xsrenumeration value="speech"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="DataSegment" minOccurs="0" maxOccurs="unbounded"> 

<xs:annotation> 

<xs:documentation>A segment of the source data processed in generating the claim. 
</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="SourceDataSegment" type="xs:string"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="KbClaim"> 

<xs:sequence> 

<xs:element name="PredicateClaim"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="PredicateName" type="xs:string" default="Persuasion Attempt"/> 
<xs:element name="Speaker"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Entity" type="stepd:Entity"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Target"> 

<xs:complexType> 

<xs:sequence> 
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<xs:element name="Entity" type="stepd:Entity" maxOccuns="unbounded"/> 

</xs:sequence> 

<xs:attribute name="type" type="xs:string" default="directed"> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="Entity"> 

<xs:sequence> 

<xs:element name="id" type="xs:integer"/> 

<xs:element name="type" type="xs:string" default="person"> 

<xs:annotation> 

<xs:documentation> "type" refers to the entity being either a person or a 
group</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="role" type="xs:string"> 

<xs:annotation> 

<xs:documentation> "role" refers to the wether the entity is either the speaker or 
target</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="KbEvidence"> 

<xs:sequence> 

<xs:element name="EvidenceValue" type="xs:string"> 

<xs:annotation> 

<xs:documentation>An overall assessment of the degree to which the set of evidence 
statements support the claim. It can be a Bayesian probability^ an interval 
probabilityj a fuzzy number^ a modalj a value on a Likert scalej etc. ; whatever 
the underlying theory of evidence supports. 

</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="EvidenceStatement" type="stepd:EvidenceStatement"/> 

</xs:sequence> 

</xs:complexType> 

<xs:simpleType name="Display"> 

<xs:restriction base="xs:string"> 

<xs:enumeration value="Weak Confidence."/> 

<xs:enumeration value="Strong Confidence."/> 

<xs:enumeration value="No Confidence."/> 

</xs:restriction> 

</xs:simpleType> 

<xs:complexType name="EvidenceStatement"> 

<xs:sequence> 

<xs:element name="ConstituentMultiset"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="PersuasionTactic" maxOccurs="unbounded"> 

<xs:complexType> 

<xs:group ref="stepd:PersuasionTacticGroup"/> 
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</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:group name="PensuasionTacticGroup"> 

<xs:all> 

<xs:element name="tactic" type="xs:string"/> 

<xs:element name="stantline" type="xs:integen"/> 

<xs:element natne="endline" type="xs:integer"/> 

<xs:element name="doc" type="xs:string"/> 

</xs:all> 

</xs:group> 

<xs:complexType name="KbSupport"> 

<xs:sequence> 

<xs:element name="TheoneticalFrame" type="xs:string"/> 

<xs:element name="TechnicalTerm" maxOccuns="unbounded"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="TechnicalTermGloss" type="xs:stning"/> 

<xs:element name="DataSnippet" type="xs:string"/> 

</xs:sequence> 

<xs:attribute name="tertn" type="xs:string" default="redefinition"/> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="KbAssertion"> 

<xs:sequence> 

<xs:element name="AssertionMetadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="AssertionId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>Performer team generated ID for this 
assertion.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="AssertionDtg" type="xs:dateTime"> 

<xs:annotation> 

<xs:documentation>Performer team generated DTG on which this assertion was 
created.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="AssentionFlag" type="stepd:AssertionFlag"> 

<xs:annotation> 

<xs:documentation>Performer team generated flag that indicates whether this is a 
"public" or "private" assertion.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="AssertionContext"> 

<xs:complexType> 
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<xs:sequence> 

<xs:element name="LanguageUseDotnain" type="xs:string" default="Pensuasion 
Attempt"> 

<xs:annotation> 

<xs:documentation>A string that specifies the Language Use domain that the 
assertion targets. Will ultimately be an enumerated list.</xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs:element name="DataSet" type="stepd:DataSource"> 

<xs:annotation> 

<xs:documentation>The data set from which the evidence for the claim is 
drawn.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="AssertionClaim" type="stepd:KbClaim"/> 

<xs:element name="AssentionEvidence" type="stepd:KbEvidence"/> 

<xs:element name="AssertionSupport" type="stepd:KbSupport"/> 

</xs:sequence> 

</xs:complexType> 

<xs:simpleType name="AssertionFlag"> 

<xs:restriction base="xs:string"> 

<xs:enumeration value="private"/> 

<xsrenumeration value="public"/> 

</xs:restriction> 

</xs:simpleType> 

<xs:simpleType name="ServiceState"> 

<xs:annotation> 

<xs:documentation>Type that defines the state that a service capability can be 
in.</xs:documentation> 

</xs:annotation> 

<xs:restriction base="xs:string"> 

<xsrenumeration value="available"/> 

<xsrenumeration value="unavailable"/> 

<xsrenumeration value="unsupported"/> 

</xs r restriction> 

</xs r simpleType> 

<xs r complexlype name="ServiceStatusReport"> 

<xsrannotation> 

<xsrdocumentation>Type that defines the status report generated by a Performer 
team.</xs rdocumentation> 

</xsrannotation> 

<xs r sequence> 

<xs relement name="KbUpdateCapability"> 

<xs r annotation> 

<xsrdocumentation>Status of the KbUpdate capability. Current state and DTG of last 
kb update.</xsrdocumentation> 

</xs rannotation> 

<xs r complexType> 

<xs r sequence> 

<xsrelement name="State" type="stepdrServiceState"/> 

<xsrelement name="LastDtg" type="xsrdateTime"/> 

</xs r sequence> 

</xs r complexType> 

</xs relement> 
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<xs:element name="DataPushCapability"> 

<xs:annotation> 

<xs:documentation>Status of the DataPush capability. Current state and DIG of last 
data push.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="State" type="stepd:ServiceState"/> 

<xs:element name="LastDtg" type="xs:dateTime"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="ExplanationGetCapability"> 

<xs:annotation> 

<xs:documentation>Status of the ExplanationGet capability. Current state and DIG 
of last explanation returned.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="State" type="stepd:ServiceState"/> 

<xs:element name="LastDtg" type="xs:dateTime"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexlype name="StatusRequestBundle"> 

<xs:annotation> 

<xs:documentation>Type that defines a STEP server request for a status check. 
Currently not used.</xs:documentation> 

</xs:annotation> 

</xs:complexType> 

<xs:complexType name="StatusReturnBundle"> 

<xs:annotation> 

<xs:documentation>Type that defines the Performer team response to a status check 
request.</xs:documentation> 

</xs:annotation> 

<xs:sequence> 

<xs:element name="Payload"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="StatusReport" type="stepd:ServiceStatusReport"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="ExplanationRequestBundle"> 

<xs:annotation> 

<xs:documentation>Type that defines a STEP server request for an explanation. 
Currently minimally specified.</xs:documentation> 

</xs:annotation> 

<xs:sequence> 

<xs:element name="Metadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="AssertionId" type="xs:string"> 
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<xs:annotation> 

<xs:documentation>STEP ID of the assertion for which an explanation is 
requested.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="ExplanationReturnBundle"> 

<xs:annotation> 

<xs:documentation>Type that defines the Performer team response to an explanation 
request. Currently a placeholder.</xs:documentation> 

</xs:annotation> 

<xs:sequence> 

<xs:element name="Metadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="AssertionId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>STEP ID of the assertion that this explanation refers 
to.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Payload"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Assertion" type="stepd:KbAssertion" maxOccurs="unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

<xs:element name="StatusReportRequestMsgPart"> 

<xs:annotation> 

<xs:documentation>Used in a message sent by the STEP server to request a Performer 
team capability status check.</xs:documentation> 

</xs :annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Metadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="MessageId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>Message ID generated by the STEP server.</xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs:element name="RequestorId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>ID of the requestor (typically the STEP server) of the status 
report.</xs:documentation> 

</xs:annotation> 
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</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="StatusReportResponseMsgPant"> 

<xs:annotation> 

<xs:documentation>Used in a message sent by a Performer team in response to a 
StatusReport request.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Metadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="MessageId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>ID of the status request message to which this message is a 
response.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="RequestorId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>ID of the ultimate requestor of the status check. Typically the 
STEP server.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Payload"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="StatusReturnBundle" type="stepd:StatusReturnBundle"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="ExplanationGetRequestMsgPart"> 

<xs:annotation> 

<xs:documentation>Used in a message sent by the STEP server to request an 
explanation for an assertion.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Metadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="MessageId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>Message ID generated by the STEP server.</xs:documentation> 
</xs:annotation> 

</xs:element> 
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<xs:element name="RequestorId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>ID of the requestor (typically a user) of the 
explanation.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Payload"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="ExplanationRequestBundle" 
type="stepd:ExplanationRequestBundle"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="ExplanationGetResponseMsgPart"> 

<xs:annotation> 

<xs:documentation>Used in a message sent by a Performer team in response to an 
ExplantionGet request.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Metadata"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="MessageId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>ID of the explanation request message to which this message is a 
response.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="RequestorId" type="xs:string"> 

<xs:annotation> 

<xs:documentation>ID of the ultimate requestor of the explanation. Typically an 
end-user.</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Payload"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="ExplanationReturnBundle" type="stepd:ExplanationReturnBundle"/> 
</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:schema> 
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